Clean Code vs. Implementation Patterns

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. 🙂

Well, it turns out that the books don’t really disagree that much. The difference is that Robert Martin is very convinced that he is describing a good way to do things for all of us, while Kent Beck’s tone is more neutral, humbly presenting the patterns that have allowed him personally to become a better programmer. I guess it’s a matter of taste, but I actually preferred Clean Code’s boldness. Another big difference is that Clean Code contains a lot more actual code (the subject of both books after all) than Implementation Patterns. The bit in Clean Code’s introduction about not skipping the case studies with that code lest the book be just another “feel good” book on programming is very true. I’m not sure, but it seems to me as if that line was directed towards Kent Beck’s effort. 😉

Besides those differences, the nice thing both books share is the refreshing new focus on the small things that make us better programmers. After we all read GoF’s Design Patterns, a lot of books were talking about design patterns and then about architecture patterns. And after that our attention shifted towards process (XP, Agile). It is good to remember that the “mundane” task of writing code is something we still can and must improve.

Something else these books share is one very important value to keep in mind when writing code. And that is Communication (as Kent Beck summarizes it in one word). The code you write will be read more times than it was written and by more people. So to minimize the cost of maintenance, your code should be clear to those people (or yourself) reading it a later date. It should be nice to read, it should clearly communicate its design, and it should not be overly complex.

This comes forward in such heuristics (as they are called in Clean Code) or patterns (as Implementation Patterns refers to them) as:

• 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!