Clean Code

published

2015-04-12

rating

4

This book provides a good overview of best practices for coding. I liked that it took concrete opinionated stances like:

1. “The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.” (p6)

2. "Indeed, the ratio of time spent reading vs. writing is well over 10:1. We are constantly reading old code as part of the effort to write new code. ... So if you want to go fast, it you want to get done quickly, if you want your code to be easy to write, make it easy to read." (p14)

3. "Functions should not be 100 lines long. Functions should hardly ever be 20 lines long." (p34)

4. "In order to make sure that our functions are doing "one thing," we need to make sure that the statements within our function are all at the same level of abstraction." (p36)

5. "Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification—and then shouldn't be used anyway." (p40) I think this rule is far too strict, though I agree that new data structures should be created where appropriate to reduce the number of arguments.

6. "Flag arguments are ugly. Passing a boolean into a function is a truly terrible practice." (p41) I think there are some cases where boolean arguments are acceptable, especially if they are expressed as a keyword argument.

7. "Command Query Separation: Functions should either do something or answer something, but not both." (p45)

8. "Try/catch blocks are ugly on their own right. They confuse the structure of the code and mix error processing with normal processing. So it is better to extract the bodies of try and catch blocks out into functions of their own." (p46)

9. "Duplication may be the root of all evil in software." (p48)

10. "So if you keep your functions small, then the occasional multiple return, break, or continue statement does no harm and can sometimes even be more expressive than the single-entry, single-exit rule." (p49)

11. "The proper use of comments is to compensate for our failure to express ourself in code. ... though comments are sometimes necessary, we will expend significant energy to minimize them." (p54)

12. "Variables should be declared as close to their usage as possible." (p80)

13. "I have found, however, that this [horizontal] kind of alignment is not useful. The alignment seems to emphasize the wrong things and leads my eye away from the true intent." (p87)

14. "Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code." (p124)

15. "It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally." (p250)

16. "Using floating point numbers to represent currency is almost criminal." (p301)

It also covers many important concepts like: "G34: Functions Should Descend Only One Level of Abstraction", The Law of Demeter, Data/Object anti-symmetry, the DRY principle, the importance of naming, and more.