Clean Code: A Handbook of Agile Software Craftsmanship

Robert C. Martin (2008)
Review date: October, 2008
Summary

"Clean Code" is divided into three parts. In the first part the author gives his view of what clean code is and how to achieve it. Things like naming, function length and composition, comments, formatting, and error handling take up the first part. The author makes an in-depth dive into these topics and discusses them throughly.

What the middle part of this book is about is not quite clear. Chapters 11 through 13 are called "Systems", "Emergence", and "Concurrency", and gather some thoughts and pointers related to separation of concerns, duplication and multi-threaded programming. Then comes a massive chapter on evolving an argument parser ("Successive refinement"), followed by two more chapters on refactoring of JUnit and class called SerialDate.

Finally, there's catalog of "Smells and Heuristics" that lists all such concepts discussed in the book.

Opinion

Since this book is treating code at such a fundamental level, it deserves both a structural and technical review. Here we go!

This is a book of extremely uneven quality! The first part, where the building blocks of clean code are discussed, is simply excellent. You witness a professional's years of experience distilled into 150 pages of well formulated advice.

But then something happens. I still can't understand what the three chapter's in the middle have to do with clean code. Of course, they sort of give you dos and don'ts, but it's as if they were pasted from another book. Maybe having different authors does this to a book (these chapters are written by three different people), but regardless of that fact, this is an unwelcome break. The "Systems" chapter makes some good points. I especially liked the discussion of EJB from the aspects perspective. However, it's poorly integrated with the rest of the material, and tries to cover too much ground in too limited space.

What emerges from "Emergence"... You tell me! A short chapter saying something about duplication being bad and design being good if testing is involved. Correct, once again, but too short and fuzzy. The concurrency chapter is quite OK, out of place, but OK.

Then comes something very novel (at least to me): 100 pages of code case studies. Three chapters on refactoring and applying the principles from the first section in practice. Personally I think one chapter would have sufficed.

In the introduction the author urges us to work hard with the code in this book. I was really prepared to do that, but came out disappointed. Reading 50 pages of step-by-step refactoring of a failed argument line parser does make you work hard, but perhaps not in the way the author had intended. Yes, this may be called pedagogy, and maybe this approach hasn't been tried before, and maybe this is extremely helpful to everybody, but then again it makes the book unbalanced. Doing this for another two chapters, and then having the SerialDate class' code listing occupy 60 pages in the appendix shifts the entire focus of this book.

On the other hand, if you perceive refactoring as something abstract, and want to see it in practice, this might just be perfect for you. Give it a try.

Now let's get to the technical analysis where look at smaller things, almost getting picky.

In the beginning the author refers to a term he calls "code-sense". It's the inherit ability to produce good code and spot bad code. According to the author, you're either born with this ability or you have to work hard to acquire it. It's a sound topic to discuss, but I'd like to make my contribution to demystifying "code-sense". You're more or less born or used to having a sense of general order around you. However, code can be classified as good or bad by some very objective criteria, such as discussed in this book. This may not have too much to do with the review, but I just wanted to say that.

A couple of paragraphs later we learn something cute but deep - the boy scout rule: leave the code in a better state than you found it by applying tiny mini-refactorings. I whole-heartedly agree with the author. If everybody did this we would never encounter bad code.

Now things get a little complicated. Time to critisize.

My general impression, being enforced here and there throughout this book, is that the author is not a testing guru. We see evidence of it once in a while. The worst sin is code duplication between (and within!) tests and the tested code. On a related subject, in chapter 8, a guest author does something that feels funny under the banner of "learning tests". In this shape, the learning tests are normal API calls, without any assertions or verifications executed as JUnit tests. Why would you do that?

Continuing the topic, it can be mentioned that the author promotes functions with as small argument lists as possible. While this is a good thing, it's generally easier to test a function that may take a longer argument list that makes is verbose. Passing half-initialized organizer objects tends to make testing harder. Of course, I agree with the author, but I'd like to have that nuance pointed out. To summarize, there are certainly good points being made about testing, but let this not be your primary book on the subject.

Since this book contains a lot of assertions, a subjective review could go on for ever, so I'm dropping it for now. However, I do have to highlight the biggest sin ever in a book on clean code! The author doesn't use curly brackets for one-line if/for/while statements. This might seem picky, but a book on clean code should acknowledge the fact that the Java coding conventions have settled this one and it's a source of many errors. Shame.

That was a lot of text. Let's summarize.

This is very good book. You may or may not agree with some of the pointers the author gives you, but in general they are sound. This book does contain some promising chapters in the middle that contain good an relevant points without quite making it. Too bad. In my opinion, there's too much text covering the refactoring examples, but some people might like it. It's a buy.

Who should read this book

The first part of this book should make it into everybody's coding conventions. Every programmer, regardless of language should read these pages. As for the second part, it might be useful for developers not too familiar with refactoring.




News

  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.