Robert C. Martin is one of the giants of object-oriented design, and a founding father of the agile manifesto and of agile software development. More recently, he helped kickstart the software craftsmanship movement, which gained much attention from his keynote at Agile2008 and subsequent talks on craftsmanship and ethics.

Mr. Martin also has a bold reputation for being ever so pragmatic, and to the point, with a flair and passion that is ever present throughout the book, as exemplified by gems such as the following from Clean Code Tip of the Week #1 (available online from the "Extras" tab of the InformIT site for the book):

"Duplicate code is the root of all evil in software design. When a system is littered with many snippets of identical, or nearly identical code, it is indicative of sloppiness, carelessness, and sheer unprofessionalism. It is the guilt-edged responsibility of all software developers to root out and eliminate duplication whenever they find it."

This is vintage Uncle Bob -- he pulls no punches! And he also believes that books about programming should contain lots of real world coding examples. The book is almost littered with working code examples, including an appendix of some 60 or so pages of code listings.

I shouldn't give Uncle Bob all the credit though. Several chapters and sections were written by some of his other ObjectMentor peers: Tim Ottinger, Michael Feathers, Jeffrey Langr, Bret Schuchert, James Grenning and Dean Wampler. They make it very clear in chapter 1 (which is available online) that this book represents their school of thinking on what constitutes clean code:

"This book will tell you, in hideous detail, what I and my compatriots think about clean code. ... We will present these opinions as absolutes, and we will not apologize for our stridence. To us, at this point in our careers, they are absolutes. They are our school of thought about clean code. ... But don't make the mistake of thinking that we are somehow "right" in any absolute sense.

... Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. That's fine. We can't claim final authority. On the other hand, the recommendations in this book are things that we have thought long and hard about. We have learned them through decades of experience and repeated trial and error. So whether you agree or disagree, it would be a shame if you did not see, and respect, our point of view."

As the back cover notes, Clean Code is divided 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. The third part a single chapter containing a list of heuristics and "smells" gathered while creating the case studies. Readers should expect to learn:

• How to tell the difference between good and bad code
• How to write good code and how to transform bad code into good code
• How to create good names, good functions, good objects, and good classes
• How to format code for maximum readability
• How to implement complete error handling without obscuring code logic
• How to unit test and practice test-driven development

The early chapters cover naming conventions, functions, comments, formatting, objects & data-structures, and error-handling. Middle chapters cover boundaries, unit-testing, and classes. After that it gets a bit more advanced and we encounter topics like: systems and scaling-up, emergence, concurrency and successive refinement. These cover some of the basic principles of design such as the single-responsibility principle, the DRY principle, the Law of Demeter, as well as many common design patterns.

Along the way we also learn some heuristics and corollaries to these principles, as well as:

· The FIRST Rule of Clean Tests

· The Three Laws of TDD

· The Four Rules of Simple Code

As an added bonus, we also learn about aspects, DSLs, dependency injection, active records, and numerous testing automation tools.

But perhaps the most important rule of all that we learn is The Boy Scout Rule, for it personifies the professional work-ethic that writing Clean Code is all about:

"It's not enough to write the code well. The code has to be kept clean over time. We've all seen code rot and degrade as time passes. So we must take an active role in preventing this degradation.

The Boy Scouts of America have a simple rule that we can apply to our profession.

* Leave the campground cleaner than you found it.

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn't have to be something big. Change one variable name for the better, break up one function that's a little too large, eliminate one small bit of duplication, clean up one composite if statement.

Can you imagine working on a project where the code simply got better as time passed? Do you believe that any other option is professional? Indeed, isn't continuous improvement an intrinsic part of professionalism?"

If you are at all serious about programming, then as soon as you finish reading this review you should get your hands on Clean Code as fast as you can! Get it. Read it. Learn it. Then live it!

About the Reviewer
Brad Appleton is an enterprise SCM/ALM solution architect for a Fortune 100 technology company. Currently he helps projects and teams adopt and apply agile development & SCM practices. Brad also author's the Agile CM Environments blog, and is co-author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, the "Agile SCM" column in CMCrossroads.com's CM Journal, and is a former section editor for The C++ Report. Since 1987, Brad has extensive experience using, developing, and supporting SCM environments for teams of all shapes and sizes. He holds an M.S. in Software Engineering and a B.S. in Computer Science and Mathematics.

Comments (0)

Write comment

Show/hide comment form