Criminal Code of the developer

The article from the section "sore." How many copies are already broken about clean code, design patterns, proper design principles, and so on. But for now, as before, every second project that comes across to our eyes, especially a non-public project that rests in a deep enterprise, has signs of a criminal offense.

I’m not talking about the “Administrative Code”, where I’m referring to the incorrect use of templates, non-use of tests, non-optimized code, even harkoding some settings and "magic numbers" (although already on the verge). In these cases, different law enforcement practices. For example, optimized code is often more difficult to understand than non-optimized. A non-optimal algorithm is often easier to read when reading a code, and the developer reads his or someone else's code 95% of the time and writes only 5%. Or if you are writing a script for a friend for free, faster and zaadkodili a couple of settings, you probably did the right thing. Having decided that integration of the logic of extracting settings (and testing it) from separate configs will take much longer time than the hardcode.

But there are signs that definitely say that your code is seriously ill and contains crime without any excuses.

Article 1. Commented Code

How often it happens in projects of any level, the person seems to be telling you: I’m not sure a little, maybe it’s still needed, or maybe I’m not, I’ll just leave it here for now. Typical code shredder. There are even whole commented modules. Again, this greatly affects the readability of the code, even though it comes in a different color. The solution is - just delete, that's all. But if you are such a junkie, you can make a special branch in git with the name for example warehouse-of-old-trash and your soul will be calm.
')

Article 2. Dead code. Dead addictions

Looks like the first article, but not quite. There is more weight. If comments your brain still at the level of color recognition refers to unnecessary, then with a code that is never executed or executed, but the result of the work goes nowhere, everything is much more complicated. It is not always clear why this code is there and what to do with it. And if there is a mistake somewhere, then look for it in this place or skip it. The worst thing is that this code is still needed and maintained. For example, the version of the dependency has been updated, which it uses and it stopped working, the system is not going to, and you have problems out of the blue. The same can be said about the dead dependencies that you have, but are not used.

Here you can add stupid stubs. For example, yesterday I saw this:

if (true){
  someFunction();
}

: « ?», : « , ». ? :

//    -, 
someFunction();

, , .. « ». Promise.delay(4000) — - , . , , .

3.

StackOverflow , , , . -, so. , . . , - , , - , . .

4.

, - . , (± ). github - , 3 , , - . , - . , , , , .

. . , , . - , . , , — .

. . , , — .

P.S. , , . , « » , 100% . , ( ) .