image I just completed Robert C. Martin latest book Clean Code "A Handbook of Agile Software Craftsmanship", which was a good read but far from as good as his Agile Principles, Patterns and Practices book which I rank among my favorite programming books. If you haven't read it stop reading this and go read it! No just kidding stay..  

Clean Code begins with an interesting chapter where the concept of clean code is defined. The chapter includes about a dozen of quotes from famous programmers who are asked to define what clean code means to them. They were all good but I especially liked Michael Feathers definition (author of working effectively with legacy code):

/.../ Clean code always looks like it was written by someone who cares. /.../

I think this is very true, if you really care about the code you write you won't leave it in a messy state but continue to refactor it until your are satisfied.

So why clean code? Well Martin argues, correctly, that the time spent reading vs writing code is very high, and that we are constantly reading old code in order to write new code. So making it easier to read will make it easier to write.

image

So how do you write clean code? Well that is what the next chapters cover, for example meaningful names, small functions,  formatting, unit tests, etc. There are a lot of code in some of these chapters, and I mean a lot. So it can be pretty tedious at times. Robert tries to show step by step how he improves some existing pieces of real code but I found it hard to really follow exactly what he was doing as the code pages were so long and there was no color highlight to mark changed lines or syntax.

I think Robert should consider doing screencasts on writing clean code or on doing TDD, it is a medium that is better suited to showing how you in small steps evolve and change code. These could then later be included on CDs with his books.

Anyway despite it's problems Clean Code is still a good read. I did learn a few new tricks and will be more strict on keeping my functions shorter :)

4 comments:

J.P. Hamilton said...

I'm halfway through and enjoying it immensely. I would recommend that people read the PPP book first, then Clean Code, and then move on to Refactoring. I think the book would have been a little better if some of the older material had been taken out. For instance, the section discussing why it is not good to return error codes. Seems to me that stuff would have been cutting edge in 1995, but everyone knows to use exceptions if the language provides for it and why they are better. Still, an excellent book. One of the better programming books I have read this year.

Torkel Ödegaard said...

I agree, read the PPP book before clean code.

For my next book to read I am thinking about: Emergent Design: The Evolutionary Nature of Professional Software Development, or some F# book like F# for scientists :)

Andreas Öhlund said...

I finished the PPP book last night (finished clean code a few weeks ago, we must have the same "reading pipeline":) ) and I really liked it. Especially the part when Robert describes the conversation between him and his partner during TDD:ing of the bowling game app. I think it really highlights the benefits of both TDD and pair programming.

Fowlers "refactoring" is next in my pipeline...

Joakim Sundén said...

I am not so sure you should read PPP before Clean Code, it probably depends on your previous experience, but I think that many principles in PPP can be difficult to take in and put to use for inexperienced OO practitioners, while much of the advice in Clean Code is of immediate use even for beginners.

I read Emergent Design a while back and it surprised me that the book had so much to say about professionalism and the profession of software development, much like Bob Martins Clean Code (and other writing/speaking). As you might know, this is a topic of great interest to me, and I found Bains take on the subject very interesting. However, the parts about emergent design left me a little bit disappointed because it was very much centered around design patterns and TDD from a beginners perspective. That said, Bain has interesting points of view on both that I have not encountered elsewhere so its definitely worth reading.