People who code: we want your input. Take the Survey
304

No. This is woefully and terribly misguided. Java features are not somehow better than C++ features, especially in a vacuum. If your programmers don't know how to use a feature, train or hire better developers; limiting your developers to the worst of your team is a quick and easy way to lose your good developers. YAGNI. Solve your actual problem today, ...


283

This would constitute a feature known as a time bomb. DON'T CREATE TIME BOMBS. Code, no matter how well you structure and document it, will turn into an ill-understood near-mythical black box if it lives beyond a certain age. The last thing anyone in the future needs is yet another strange failure mode that catches them totally by surprise, at the worst ...


275

If I were in your shoes, I would probably try it this way: first, finish the current project - at least partially - as soon as possible, but in a working state. Probably you need to reduce your original goals, think about the minimum functionality you really need to see in "version 1.0". then, and only then think about a rewrite from scratch (lets call ...


239

I'm going to make an argument for == Douglas Crockford which you cited is known for his many and often very useful opinions. While I'm with Crockford in this particular case it's worth mentioning it is not the only opinion. There are others like language creator Brendan Eich who don't see the big problem with ==. The argument goes a little like the ...


218

In layman's words: The important thing is not the numbers of lines but the readability of the code. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (M. Fowler) In the examples you gave, the second one is definitively easier to read. Source code is for people to read. Besides, ...


177

As an exercise, first let's verify your logic. Though as we'll see, you have bigger problems than any logical problem. Call the first condition A and the second condition B. You first say: Looking specifically at section two, I know that if section one is true, then section two will also be true. That is: A implies B, or, in more basic terms (NOT A) ...


177

You can loosely replicate the role source control plays with three simple tools: Back-up software (Commits/Check-ins) Folders (Branches) Performing a directory merge between two directories using a tool like KDiff3 (Merging branches) Basically your workflow becomes: Create a new folder (new branch) Copy files to the new folder (new branch) from an ...


165

To answer your question about extant research But has anything been written or researched on recognizing the point where striving for code brevity stops being useful and becomes a barrier to comprehension? Yes, there has been work in this area. To get an understanding of this stuff, you have to find a way to compute a metric so that comparisons can be ...


159

The principles stated in "Clean Code" are not always generally agreed upon. Most of it is common sense, but some of the author's opinions are rather controversial and not shared by everybody. In particular, the preference for short methods is not agreed on by everybody. If the code in a longer method is not repeated elsewhere, extracting some of it to a ...


143

Just because the syntax seems similar on the surface doesn't mean that the two languages are compatible. 1, 4 and 5 are really the same question: Now, I'm no fan of C++, but saying "Code without C++ specific features is usually more maintainable" is just ridiculous - do you really believe that Java got everything right, and took all the good features while ...


139

Although the consensus would certainly be to not work for this company I don't believe that really answers your question. You can't really replace SCM. You might not need the usual bells and whistles of a full-blown system. For example, the company may refuse a request for a server, but permit the use of a local SCM. They may dislike git, but permit ...


122

A thin person isn't necessarily healthier than an overweight person. A 980 lines children story is easier to read than a 450 lines physics thesis. There are many attributes that determine the quality of your code. Some are simply computed, like Cyclomatic Complexity, and Halstead Complexity. Others are more loosely defined, such as cohesion, readability, ...


119

Finished IT projects, even faulty ones, are much better than unfinished ones. Unfinished ones can teach you a lot too, but not as much as finished ones. You may not see it now, but you get an enormous amount of value working with even faulty code. My vote goes for finishing and then, maybe, refactoring - if needed. When you start working with more ...


118

Firstly, magic values are avoided in programming by using variables or constants. CSS does not support variables, so even if magic values were frowned on, you don't have much of a choice (except using a preprocessor as SASS, but you wouldn't do that for a single snippet). Secondly, values might not be as magic in a domain specific language like CSS. In ...


115

Never forget the Law of Demeter: The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling. The guideline was proposed by Ian Holland at Northeastern University towards the end of 1987, and can be ...


104

Not all magic numbers are the same. I think in that instance, that constant is OK. The problem with magic numbers is when they are magic, i.e. it is unclear what their origin is, why the value is what it is, or whether the value is correct or not. Hiding 1024 behind BYTES_PER_KBYTE also means you don't see instantly if it is correct or not. I would expect ...


103

It depends, and your example is not useful in making the decision. While fewer lines of code are not always better (at some point it leads to obfuscation), they usually are, simply because there's fewer things to keep track of when trying to understand the code. In your specific example: If the names of the intermediate values actually convey meaning that ...


102

Well written code should be sufficiently self-documenting that you don't need any comments explaining what the code does, because it is obvious from reading the code itself. This implies also that all functions and variables have descriptive names, although it might be needed to learn the lingo of the problem and solution domains. This does not mean that ...


100

It turns out that jQuery uses the construct if (someObj == null) { // do something } extensively, as a shorthand for the equivalent code: if ((someObj === undefined) || (someObj === null)) { // do something } This is a consequence of the ECMAScript Language Specification § 11.9.3, The Abstract Equality Comparison Algorithm, which states, among other ...


94

I will answer your questions in order. If Java doesn't provide a feature that C++ has, it means that the feature is not good, so we should prevent using it. Yes, any feature not present in Java is anathema on the hard drive. It must be burned from your code base. Those who do not obey will be scrounged, their souls used to placate the RAID gods. C++ ...


89

What you are doing in the code you're showing above is not so much future proofing as much as it is defensive coding. Both if statements test for different things. Both are appropriate tests depending on your needs. Section 1 tests for and corrects a null object. Side note: Creating the list doesn't create any child items (e.g., CalendarRow). Section 2 ...


87

You need to consider the cost of change. What if you wanted to change how connections are made? How easy would it be? If you have a lot of duplicated code, then finding all the places that need changing could be quite time consuming and error prone. You also need to consider clarity. Most likely, having to look at 30 lines of code isn't going to be as ...


87

If you think the code should be fixed before merging, make comments. Preferably with "why" so the dev can learn. Keep in mind code is read far more often than written. So things which seem "minor" can actually be really important (variable names for example). However, if you find yourself making comments which seem tedious, perhaps consider: Should your ...


84

There are several questions that you raise. 1) Is this a clear sign that the coder is not cut out for professional programming? No. Developers often go through stages where they learn about an idea and want to apply it. Do they always apply these ideas efficiently and/or effectively. No. Mistakes are made, and it is part of the learning process. If ...


83

Good answer here already, but let me say a word about your butterknife example: though I have no idea what the code does, at a first glance, it does not look really unmaintainable to me. Variables and method names seem to be chosen deliberately, the code is properly indented and formatted, it has some comments and the long methods at least show some block ...


80

It's acceptable because these formats are not code, but data. If you were to remove all the "magic numbers," you would essentially duplicate every label, and end up with ridiculous looking files like: mainkite_width = 200px ... .mainkite { width: mainkite_width; ... Every time you needed to change some data, you would need to look in two places. ...


78

There are several relevant trade-offs here: Review complexity. If a branch has more than one functional change commit or more than one refactoring commit it becomes time-consuming to review the result, since now each commit has to be reviewed separately. Risk. Any refactoring, no matter how well the code is tested, has some non-zero risk of breaking things. ...


74

In some programming languages, order does matter because you can't utilize things until after they've been declared. But barring that, for most languages it doesn't matter to the compiler. So then, you're left with it mattering to humans. My favorite Martin Fowler quote is: Any fool can write code that a computer can understand. Good programmers write code ...


73

Code is just a means to an end. What that end might be varies, but typically it's profit. If it is profit; then to successfully argue anything you want to show that it will improve profit - e.g. by increasing sales, reducing maintenance costs, reducing development costs, reducing wages, reducing retraining costs, etc. If you can't/don't show that it will ...


Only top voted, non community-wiki answers of a minimum length are eligible