I’ve just read Robert C. Martin’s Clean Code and Kent Beck’s Implementation Patterns back to back. I actually picked up Clean Code first because my colleagues were raving about it. But then Robert Martin’s book quotes from Kent Beck’s book on the third page of the first chapter already, and disagrees with the quote, so I decided it’d be fun to read Implementation Patterns too. 🙂
- Choose Descriptive Names (CC) / Intention-Revealing Name (IP) – Think about the names you give your classes, methods, etc. Instead of just starting with get or set and slapping on a word or two, actually describe what is going on. If you can’t do that succinctly then maybe you need a better abstraction.
- Functions Should Descend Only One Level of Abstraction (CC) / Composed Method (IP) – Split up large methods so that they deal just one level of abstraction, delegating work to other methods for work on a lower level of abstractions. Not only does this make the code easier to understand, you may also discover reusable bits of code this way. Doing this is easy to do with the support modern IDE’s have for refactoring operations such as “Extract Method”.
- Use Explanatory Variables (CC) / Role-Suggesting Name (IP) – Split up complex calculations by using local variables with descriptive names. Like the previous pattern, this helps the reader of your code to understand what is going on. Modern IDE’s have the “Extract Local Variable” refactoring operation to do this.
One nice advantage of following these patterns or heuristics is that it allows you to do away with a lot of comments. Comments that are sometimes redundant, that are bound to become obsolete, and that may even misguide the reader if not properly maintained. Having learned to program in the late eighties (when writing comments was what a good programmer was supposed to do), this felt a bit strange at first. But now, when I feel the need to explain a block of code by starting a comment, I know that I need to extract that block into a separate method. 🙂
While both books inspired me a lot, there were a few thing I did not like. To start with Clean Code: while Robert Martin’s prose is very enticing, the chapters contributed by other people were not up to the same level. The chapter on Emergence did not offer any new insights, and the chapters on Concurrency seem simplistic. At least to someone that has read Brian Goetz’ excellent Java Concurrency in Practice. Also, the coding style where fields are preferred over method arguments (as exemplified by the Args example in chapter 14) seems to be asking for concurrency problems to me. It looks like the Hidden Temporal Couplings smell mentioned in the same book. As for Implementation Patterns; as I mentioned before, I would have liked the book to include more code. Also, some of the patterns are not really patterns but rather descriptions of a programming concept (“Class”, “Initialization”, “Parameter”, etc.). So while the back cover of the book promises 77 patterns, you are actually getting less. 😉 And there is one pattern that I think is very dangerous; I’ve seen people misinterpreting the eager initialization pattern so many times, that I would have loved to see a move-the-declaration-to-the-initialization-instead-of-the-initialization-to-the-declaration pattern. And finally, while the last chapter describes some nice patterns to use when writing a framework, these patterns are not applied to the timer framework in appendix A that immediately follows. One thing I dearly miss in both books is how to deal with existing frameworks. Most code we write does not exist in a vacuum but uses a lot of frameworks such as EJB3, Spring, Wicket or whatever. While modern frameworks are less invasive when compared to older frameworks such as EJB2, they still have an impact on your architecture as I recently discovered when using JPA on a new project (but more that in a later blog :-)). To conclude, I think these books are a valuable read for anyone who wants to become a better programmer. As they are easy to read (Implementation Patterns is only about 150 pages!) there really is no excuse to write bad code anymore!