Martin redux

Speaking of Martin, I put together a list of highlights from his book Clean Code.

Following Kent’s 4 Rules of Design

1.       Run all of the tests

2.       Contain no duplication

3.       Express the intent of the programmer

4.       Minimize the number of classes and methods

(interestingly, #3 and #4 are often at odds.  As Martin says “ High class and method counts are sometimes the result of pointless dogmatism” (page 176)).

Writing code is an iterative process.  There are several catch-phrases you can use to reinforce that point:

1.       You need to write dirty code to get clean code

2.       Red light/green light/refactor

3.       Make it work, then make it right

4.       Refactor often, even working code

The reason it is iterative is because you will not get it right the 1^st time and you need to keep refactoring to move towards the single responsibility principle, etc… 

Readable code is a must – because the average developer spends 10 times as much time reading his/her own code when writing a new line.  I am sure that number is higher when it is someone else’s code (or their own code 1 year later).  Now I see why everyone wants to work on new projects – less code to read.

Code should be so readable that you don’t need comments.  It is not ok to write a good comment to explain bad code – fix the code!

Finally, in his Smells and Heuristics section, I found many of the things that I have done that kicked off a spidy-sense warning but until now, I have realized why:

·         Obsolete Comments

·         Commented Out Code

·         Too Many Arguments

·         Dead Function/Code

·         Prefer Polymorphism to If/Else or Switch/Case

·         Functions Should Do 1 Thing

·         Functions Should Descend Only 1 Level Of Abstraction