Agile Zone is brought to you in partnership with:

Meera has posted 70 posts at DZone. You can read more from them at their website. View Full User Profile

Why You MUST Read Clean Code

  • submit to reddit

Clean Code: A Handbook of Agile Software Craftsmanship written by Robert C. Martin is one of the best books I have read in the past few years. This is the book for developers looking to produce better code. To be honest, any developer, software engineer, project manager, team lead or system analyst who develops an application or just reads code, should probably have a copy of this book on their bookshelf. Even though the examples in the book are written in Java, the book provides relevant information for developers using any language. 

This book is divided into three parts each filled with code. Part 1 describes the principles, patterns, and practices of writing clean code. Part 2 has several case studies. Part 3 is just one chapter containing a list of heuristics and "smells" gathered while creating the case studies.

Lets see the top 5 reasons why you should buy and read this book.

1. If you consider test code as second-class citizen.
If your team feels that test code should not be maintained to the same standards of quality as production code than you should read this book. The author explains the three laws of TDD, how to keep your tests clean, and the five rules for writing clean tests called F.I.R.S.T. Let me just give you a sneak peek of the rules:

    a. Fast Tests should be fast.
    b. Independent Tests should not depend on each other.
    c. Repeatable Tests should be repeatable in any environment.
    d. Self-Validating The tests should have a boolean output. Either they pass or fail.
    e. Timely The tests should be written in a timely fashion.

2. If you are using third party libraries.

Chapter 8: Boundaries discusses the best practices and techniques to keep the boundaries of our software clean. I admit, in all these years, I have written several lines of throwaway code to try these libraries. Once the code works, we add it directly in our production code. The author, however, shows us a completely different approach. The apache log4j package is used as an example in this chapter. To quote the author:

Instead of experimenting and trying out the new stuff in our production code, we could write some tests to explore our understanding of the third party code. Jim Newkirk calls such tests learning tests.

3. Throwing checked exceptions.

This is yet another topic that has been debated for quite a long time. If your code is throwing a lot of checked exceptions, you are returning a null in your catch block, and you have tons and tons of null checks everywhere in the code, then you should pay particular attention to Chapter 7: Error Handling. A few of the topics covered in this chapter  with examples are:
    a. Use Exceptions Rather Than Return Codes
    b. Write Your Try-Catch-Finally Statement First
    c. Use Unchecked Exceptions
    d. Don't Return Null
    e. Don't Pass Null

4. What's in a name?

Isn't our entire code base filled with names for our libraries, packages, classes, methods and variables. If you are naming your variables as i,j,k or methods are named like getList or getArrays than this book will help you write meaningful names. At this point I remember the following quote from the foreword written for this book by James O. Coplien

You should name a variable using the same care with which you name a first-born child.

The author uses excellent examples to show how to write code with meaningful names;
    a. Use Intention-Revealing Names
    b. Avoid disinformation
    c. Use Pronounceable Names
    d. Use Searchable Names and so on...

Not only does this book offer great advice, it also makes you laugh out loud(LOL). For example, while reading Chapter 2:Meaningful names, the author writes:

If you can't pronounce it, you can't discuss it without sounding like an idiot. "Well, over here on the bee cee arr three cee enn tee we have a pee ess zee kyew int, see?" This matters because programming is a social activity.

5. If your functions and classes are too long.

If you are doing too many things, have nested loops, and lots of indenting, go get this book.  There are several chapters which show how to refine your code, reduce the number of lines within your function, and completely remove duplication. The author takes a few examples from the open source testing tool FitNesse, and uses FitNesse to refactor some of the long functions as he goes along.

If none of the above examples bother you because you are already writing clean code, than there are several more reasons to read this book. It wil help you with: Comments, Formatting, Objects and Data Structures, and many more.

What I learnt from this book:

1. To clearly identify between good and bad code.
2. How to refactor bad code to good code.
3. Giving good names to variables, methods, classes and so on...
4. Better understanding of error handling.
5. How to Unit test 3rd party libraries.
6. And finally, Cleanliness is next to godliness.

Enjoy. Share your thoughts if you have read this book.

Published at DZone with permission of its author, Meera Subbarao.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


David Gilbert replied on Mon, 2008/10/13 - 2:04am

Nice review Meera!  This book does indeed look pretty good.  I haven't read it all yet, but some of my own *bad* code is featured in Chapter 16 "Refactoring SerialDate" (code that is still used in JFreeChart to this day).  I think we all write some good code and some bad code at various times (for a whole range of different reasons) and it is a very good idea to know all the techniques available to improve the bad stuff(**).  And this book seems a good resource for exactly that.

(**) In my experience, having someone else review your code is the single best way to get rid of the bad code.  Most of the code I write is open source, so it usually gets good external review...and over the years, I've had the opportunity to rewrite a good portion of my worst code.  I'm lucky there, because I know in many corporate environments for example, the opportunity to rework existing code isn't always available.

Meera Subbarao replied on Mon, 2008/10/13 - 5:58am in response to: David Gilbert


While I was reading Chapter 16, I thought for a moment how you and some others felt about the review going public. I commend you all for that. You very well said "having someone else review your code is the sisngle best way....". I completely agree.

Meera Subbarao replied on Mon, 2008/10/13 - 6:14am in response to: Meera Subbarao

I should also mention that I did not signup to review this book at all. Around 4 weeks back, when I came back from work the book was at my front door. I am not sure who sent it to me either. I should thank the publisher as well the author, I sure would have missed reading this.

Kenneth Mark replied on Mon, 2008/10/13 - 6:21am

Thanks for the review. This book looks interesting and reminds me lot of my mistakes.

Gian Franco Casula replied on Mon, 2008/10/13 - 7:28am

Hi Meera,

Thanks for the review.

I actually have the book on my 'If you want to buy me a present...' list :-)

And it's there just because R.C.Martin is the author, having read other titles of the same author, I thought this is a must read as well...

Meera Subbarao replied on Mon, 2008/10/13 - 7:32am in response to: Gian Franco Casula


I actually have the book on my 'If you want to buy me a present...' list :-)


I think this is a great book to gift, to colleagues, students, and anyone who writes code. As I said, someone gifted me this book, not sure whom to thank though.

Meera Subbarao

Jeroen Wenting replied on Mon, 2008/10/13 - 7:59am

Sounds like a good book, added it to my Amazon wishlist (Amazon is a good 25% cheaper than Pearson's own online store).

Carlos Silva replied on Mon, 2008/10/13 - 8:31am

It seems to be a great book. Thanks for your good review!

David Gilbert replied on Mon, 2008/10/13 - 11:56am in response to: Meera Subbarao



While I was reading Chapter 16, I thought for a moment how you and some others felt about the review going public. I commend you all for that.


Hi Meera,

I guess my ego should be dented, but after many years of releasing code to open source, I've reached a point where I just see it as an opportunity to further improve "the code".

Let me also say that Mr Martin was highly professional and contacted me a good while back to seek my permission to publish his critique.  That wasn't necessary, but I appreciate it all the same.

Genady Beryozkin replied on Mon, 2008/10/13 - 4:00pm

Looks a very interesting book, and a very nice review too!

Meera Subbarao replied on Mon, 2008/10/13 - 4:26pm in response to: Genady Beryozkin

[quote=genadyb]Looks a very interesting book, and a very nice review too![/quote]

Thanks. I have lost count of how many reviews I had written, and all of them were in the same format. So, I thought it was time for a change. Looks like it resonated well with the readers. I appreciate your comments.

Meera Subbarao

Andrew McVeigh replied on Mon, 2008/10/13 - 4:29pm

It's a very good book. I picked up my copy last week. To be honest though, almost any book from "Uncle Bob" is a bit of a classic.

The good part of Bob's writing, is that it is all based on his principles for structuring and managing dependencies. I went to one of his 4 hrs tutorials in '95 (!) in Australia and it really set me up with strong OO principles for my career and subsequent phd research.

By way of random example: here's a nugget from the book, which clarified things for me. On page 107 Bob says to throw unchecked exceptions by way of explanation: "The price of checked exceptions is an Open/Closed Principle violation". He then clarifies that "checked exceptions can sometimes be useful if you are writing a critical library." So there it is in a nutshell; Bob explains succinctly why checked exceptions lead to throw clauses propagating through the codebase, and explains why sometimes you want checked exceptions (writing APIs). Very neat. The whole book is like this.


Meera Subbarao replied on Mon, 2008/10/13 - 4:55pm in response to: Andrew McVeigh

Very well said, Andrew. This was the first book from the author which I read, and I am truly impressed.

Andrew McVeigh replied on Mon, 2008/10/13 - 5:15pm in response to: Meera Subbarao

If you are interested, Bob has a lot of good stuff online here. The following is my favourite article of his:

Principles and Patterns

It still hasn't been bettered as an introduction to dependency management in OO systems.


Meera Subbarao replied on Mon, 2008/10/13 - 6:45pm

Thanks, Andrew. I sure will read those artilces.

Nav Nel replied on Wed, 2008/11/26 - 9:20pm

Hello Meera,

I was just wondering if we have a code analysis tool in the market that integrates and works well with Grails & Groovy? Your response is very much appreciated and valued.

Many Thanks,



Meera Subbarao replied on Fri, 2008/11/28 - 10:16am

Very good question, Navatha. I haven't used any with Groovy or Grails. I sure will reserach and keep you posted here.

Praveen Kumar replied on Fri, 2008/12/12 - 3:15am

Looks a very interesting book and thanks to sharing this Meera. 

2nd and 3nd  Section more about practical (feel and over come), going through the 2nd Section, by the time I complete reading of this book, hope I keeps my code clean(Others too :-) ).

But looking at the code, How can we judge it is a good or bad code ?. Is it only consists of the naming conventions, beautification(make the life of others easier) or the funtional steps also involves(elapse time) or the quality, quantity(how many killo bytes of code generated) of code?.

Thanks, ---Praveen 







kallel wassim replied on Fri, 2013/01/25 - 12:04pm

 I have this book but I don't find a time to read , i think review  :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.