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, ...
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 ...
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 ...
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 ...
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 ...
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.
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 (...
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) ...
You can loosely replicate the role source control plays with three simple tools:
Back-up software (Commits/Check-ins)
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 ...
First off, thanks for the kind words.
If you want to get a deep knowledge of C# it is undoubtedly an advantage to have the language specification, ten years of design notes, the source code, the bug database, and Anders, Mads, Scott and Peter just down the hall. I'm certainly fortunate, no question about it.
However, even without those advantages it is ...
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 ...
Double-check your motivation. If you think the code should be changed, you ought to be able to articulate some reason why you think it should be changed. And that reason should be more concrete than "I would have done it differently" or "it's ugly." If you can't point to some benefit that comes from your proposed change, then there's not much point in ...
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 ...
Sorry to say this but,
You aren't going to want to hear this, but he is not completely wrong.
If you are doing work for hire for external companies as a consultant,
and they are willing to accept the most slapped together thing you can
do and don't complain, and are willing to come back over and over
again for you to do more work, your boss is 100%...
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 ...
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 ...
You cannot export main from a library, but you can export Py_Main, and then anyone using that library can "call" Python many times with different arguments in the same program. At that point, python becomes just another consumer of the library, little more than a wrapper for the library function; it calls Py_Main just like everyone else.
Rome wasn't built in a day, but you can be a good 'Boy Scout'. Every time you touch the code, leave it better than it was before. It doesn't take an extraordinary amount of time to use sensible function names, good coding standards and put decent comments in when you work.
I think the danger is thinking it's all or nothing. Just because you can't spend ...
Your problem appears only when your methods are long and are doing multiple tasks in a sequence. This makes the code harder to understand (and thus maintain) per se. Reusing variables adds on top of this an extra element of risk, making the code even harder to follow and more error prone.
IMO best practice is to use short enough methods which do one thing ...
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, ...
If you repeat yourself, you can create maintainability issues. If doStuff1-3 all have similarly structured code and you fix a problem in one, you could easily forget to fix the problem in other places. Also, if you have to add a new case to handle, you can simply pass different parameters into one function rather than copy-pasting all over the place.
Micro-optimization is only important if the numbers say it is.
The requirements that you are developing against should have some specification of performance data, if performance is at all an issue to the client or user. As you are developing software, you should test the performance of your system against these requirements. If you aren't meeting ...
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 ...
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 ...
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 ...
Whenever anyone asks about optimisation, I'm reminded of the quote from Michael A. Jackson
The First Rule of Program Optimisation: Don't do it.
The Second Rule of Program Optimisation (for experts only!): Don't do it yet.
Quote from Wikipedia corrected for British English. *8')
Implicit in the second rule is to profile your code and only spend time ...
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 ...
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 ...