|From this book, you’ll learn principles, patterns and practices of writing clean code through the use of case studies and discussions of open source projects. The basic premise is that code must be simple to read, easy to test, and have good test coverage. This was an easy read, yet challenging and rewarding. I feel like I can read it again a year from now and learn plenty more. The only criticism I can level at the book is that it requires you to really invest time and effort into getting the most out of it.|
This book is split into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is a single chapter containing a list of heuristics and “smells” gathered while creating the case studies.
The book begins by describing what clean code actually is. This is achieved through discussing quotes provided by people such as Bjarne Stroustrup, Grady Booch, Dave Thomas, Michael Feathers, Ron Jeffries, Ward Cunningham, and Kent Beck. The basic premise is that code must be simple to read (by people other than the author), easy to test, have good test coverage, etc. This is pretty obvious –and therefore I’m sure you have an innate sense of what clean code is. This book helps to reinforce this, and tells you how to get there.
After discussing the basics of what clean code actually is, “Uncle” Bob moves on to working through the refactoring of a few different open source projects. He begins with bad code, and steps through a number of refactorings until the code is clearly much cleaner (albeit also much longer). These chapters are very easy to skip through, so you have to be sure to stick through it and really make sure you understand the reasoning behind each step.
I’d like to quote a paragraph out of the introduction in the book which summarises precisely the importance of really thinking whilst reading this chapter. The quote goes as follows:
"If you read the first and third sections and skip over the case studies, then you will have read yet another 'feel good' book about writing good software. But if you take the time to work through the case studies, following every tiny step, every minute decision – if you put yourself in our place, and force yourself to think along the same paths that we thought, then you will gain a much richer understanding of those principles, patterns, practices, and heuristic. They won’t be 'feel good' knowledge any more. They’ll have been ground into your gut, fingers, and heart. They’ll have become part of you in the same way as a bicycle becomes an extension of your will when you have mastered how to ride it."
To summarise this book as succinctly as I can, this book felt like the missing chapters from ‘Effective Java’. After reading both books, I feel I know everything I need to know about writing top-quality Java code. In addition, I know that when I ever have a question regarding writing quality Java code that by referring to these two books I will almost certainly have an answer awaiting me. Whereas Effective Java is about teaching you the Java language and how to use it, Clean Code is focused on ensuring code is easily readable and ‘clean’. It does this by describing how to format and refactor bad code, and whilst a lot of what this book says is obvious (use good names, keep functions short, ensure your tests pass, etc), it’s still a good read, as there are certainly ideas in this book that you may have forgotten otherwise.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)