Clean Code vs. Implementation Patterns

Clean Code vs. Implementation Patterns
Posted by Vincent Partington in the late evening: January 26th, 2009

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!

Filed under Architecture, Hibernate, Java, Testing | 11 Comments »

11 Responses to “Clean Code vs. Implementation Patterns”

John K. Patrick Says:

Posted at: January 26, 2009 at 11:45 pm

Nice article mate! Patterns should be used carefully though, and not artificially bloat the whole architecture.

dennis sellinger Says:

Posted at: January 27, 2009 at 9:04 pm

I have read IP twice and am having trouble slogging through CC (but then, I have the paper version of IP and only the online version of CC).

I think IP changed the way I code simply because at one point Beck talks about code symmetry.

For me, this was the first time I have seen code symmetry articulated, but I think when we look at asymmetric code we notice that “something is wrong”, even if we don’t know what it is.

For me this was the “big new thing” of the book and I am encouraging my co-workers to read the book, just to have the concept explained (in hopes that we start to write more symmetric code).

cheers.

Alex Says:

Posted at: January 27, 2009 at 9:58 pm

Really enjoyed this article. In fact I just ordered both books; I should be able to get a real interesting and informative presentation for our professional circle from them.

Caligula Says:

Posted at: January 27, 2009 at 10:42 pm

@John K Patrick: the “patterns” referred to here are not “design patterns”.

dennis sellinger Says:

Posted at: January 28, 2009 at 12:54 pm

One more point. The more we try to write clean code (i.e. short methods that do exactly one thing), the more our code files can become a big mess of methods (in my IDE I don’t even have a way to know that a method is never called (even a private one!).

IDEs generally provide “extract method” tools, but mine (Visual Studio) does not offer any tools to reorganize the code. Result, the code file is a stream of consciousness mess of short methods.

So, I think tool providers have to start looking at doing method extraction with code reorganization in mind if we are ever to truely exploit the techniques of CC and IP.

In addition, as we start “sorting” methods, we will also have problems with source code systems that will be continually finding change conflicts. So SCM tools have to start having method granularity rather than just code file granulatiry.

So I think if we are to adopt some of these techniques, the tool providers have to start inventing new tools that will help us structure code files more easily.

Henry Ho Says:

Posted at: January 28, 2009 at 11:12 pm

I just read Clean Code: A Handbook of Agile Software Craftsmanship, and I must say, Chapter 17. Smells and Heuristics is the most awesome chapter I have ever read!

Thank you for introducing me to such a good book.

fritz freiheit.com » Link dump Says:

Posted at: January 30, 2009 at 9:57 pm

[...] Clean Code vs. Implementation Patterns | Xebia Blog (Code,Refactoring,Book,Comparison,SoftwareDevelo… [...]

Craig Jones Says:

Posted at: March 26, 2009 at 12:32 am

Thanks for comparison. I’m mostly through CC. Haven’t read IP yet, and I’m wondering if I need to bother. Based on the 3 examples you gave — “Choose Descriptive Names” (CC) vs. “Intention-Revealing Name” (IP), “Functions Should Descend Only One Level of Abstraction” (CC) vs. “Composed Method” (IP), and “Use Explanatory Variables” (CC) vs. “Role-Suggesting Name” (IP) — it seems like Martin’s CC book is more plain-spoken and therefore easier to grok. If I don’t have any questions after reading CC, will reading IP add anything? (Hmm, perhaps even if not, I should read IP anyway, just so I can communicate with other programmers who have read IP but not CC.)

Code Quality - Learn: OOPs, Desing Patterns, Clean Code and Refactoring « Jai’s Weblog - Tech, Security & Fun… Says:

Posted at: April 12, 2009 at 9:01 am

[...] For review please feel free to have a look at this Book Review and also very interesting comparison Clean Code vs. Implementation Pattern. And certainly few more enthusiastic who even say Get it. Read it. Learn it. Then live [...]

Christian Horsdal Says:

Posted at: July 3, 2009 at 6:57 am

Thanks for an interesting comparison.

About the two books not covering how to deal with exiting code: You might find Michael Feathers Working Effectively with Legacy Code interesting. I think it’s very, very good.

Vincent Partington Says:

Posted at: July 5, 2009 at 1:44 pm

@Christian: Thanks for the tip. I’ve heard more people mention that Michael Feathers’ book is an interesting one. I’ll put it on my to-read list!