306

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, ...


284

Protected variables should be avoided because: They tend to lead to YAGNI issues. Unless you have a descendant class that actually does stuff with the protected member, make it private. They tend to lead to LSP issues. Protected variables generally have some intrinsic invariance associated with them (or else they'd be public). Inheritors then need to ...


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 ...


274

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 ...


237

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 ...


217

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, ...


198

Recursion is not intrinsically better or worse than loops - each has advantages and disadvantages, and those even depend on the programming language (and implementation). Technically, iterative loops fit typical computer systems better at the hardware level: at the machine code level, a loop is just a test and a conditional jump, whereas recursion (...


176

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) ...


176

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 ...


163

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 ...


113

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 ...


107

The first rule of any professional software engineer is to write code that is comprehensible. The second example looks like an optimized example for an older, non-optimizing compiler or just someone who happens to want to express themselves with bitwise operators. It's pretty clear what's going on if we are familiar with bitwise operations but unless you're ...


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 ...


100

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 ...


98

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 ...


86

I agree with your code reviewers, but with an asterisk. Each statement that you write in your code is a technical liability -- it's a potential failure point. If you write a method with 10 statements and your coworker writes one that achieves the same functionality with 5 statements, his is likely to be 'better' as measured by likelihood of issues (there are ...


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 ...


84

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 ...


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. ...


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