Vincent Partington 13 Jul, 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.