Cosmetics Qualifications

PUBLIC GOOD CODE ...

In order, a good code

1. passes its tests successfully;
2. can be misused;
3. contains no redundancy;
4. clearly expresses the intention;
5. is as short as possible.

Paraphrase ...
A little close, points 1 , 3 , 4 and 5 is a quote from Kent Beck , creator of the -eXtreme Programming . Practitioner programming by contract, I added point 2. (What I will not cite the work Kent Beck and Bertrand Meyer in the same post: o)

... nevertheless useful
I get to read a lot of code, binommer with many developers and teach. As part of these activities, this quote five points is very useful. I use it a lot and I quote often. I'm sure as an extreme dogmatic and stubborn ... (After all in a team, it is good to achieve a certain ratio extremist developer / developer lax)
Still there is much empirical wisdom in this quote. Among other things, the order of criteria is very important .

1. You will test
testing top the podium. A code that is not tested does not have value. Code is not guaranteed. Any line of inquiry must be covered by a test. This is true very well with the analytical tools of structural coverage.

2. You disabuse
A code that can be misused is a code undeceived. It contributes to the preventive management of defects in the application. Programming by contract is an excellent practice to key the code. Quit talking about programming by contract, it would be more accurate to say "A good guarantee its postcondition code if its precondition is guaranteed by its caller" . To learn more about this rare practice but really effective, you can read a preceding post on this topic .

3. You do not repeat yourself not
Duplication is a source of multiple faults and multiple times. It undermines the clarity of intent. Suppose that I "inherits" a untested code. Without hesitation, I prefer to spend time testing it to eliminate redundancies. (Actually, I eliminate redundancy from the tests pass: o)

4. Thou shalt be clear and explicit
The code is read much more often writes - including its author! Besides, the writer is first and foremost his own player. Much easier the lives of all these reviewers. As with the previous point, I prefer test as renaming and cut. (Same, I rename and cut out the tests pass: o)

5. Thou shalt be brief
The brevity of the code comes last because it may conflict with items 1 , 3 and 4 . In such cases, the brevity is not a priority.
To make code testable, it is often necessary to create interfaces inject dependencies to build objects . This increases code size. The test also leads to cut in small classes and there is a declarative heel to pay for this modularity.
A code without duplication can lead to an operation to create two duplicate lines. In total, counting the statement by overflow, this practice may increase the number of lines. Besides, have you noticed that the revised code examples are always longer than their original code? (see Clean Code )
To make a code more explicit, we have to standardize the level of abstraction in the code of operations. For this, we encapsulate the code level of abstraction than in a transaction. Again, we pay a fee for the statement of operations. And

test code?
This codex 5 rules apply to the code, but also tests because the tests are code. One might think that we should not test if testing is never ending. However, the practice of Test Driven Developpment end of eXtreme Programming, design integrates test test !
Indeed, when we start by writing a test that fails , then we modify the code until the test passes, we verify the accuracy of the test. Th 2-step approach is to test the test.

One more (violation of criterion 3!)
Sorry, this was the 1379th ticket to define a good code. Many books devote their pages. It's like the strings of luck / bad luck. When you read one of these tickets, one must write one to turn ...