Customer Reviews

Clean Code: A Handbook of Agile Software Craftsmanship

5 star:		(64)
4 star:		(23)
3 star:		(7)
2 star:		(4)
1 star:		(5)

 

 

[Kindle Version Review]

The one star is not a reflection of the content of the book, which is clearly a very fine treatise on coding practices, but of the fact that the Kindle version is almost impossible to read. Code samples are truncated, in a variable-width font, and have less-than and greater-than symbols missing. References in the text often refer to listings that are not closely located with that text (eg. "see Listing 4-7 on page 71" is almost impossible to find on a Kindle without single-paging).

This is a book that requires a lot of page flipping, and shouldn't be available on the Kindle unless the publisher is willing to put in some effort to address these readability issues.

When you do code maintenance, you can really "love" or "hate" a person that you do not even know just by the code he or she has written. Messy code almost always goes hand in hand with lower productivity, lower motivation, and a higher number of bugs. In the first chapter, Robert C. Martin presents in a very instructive way, the opinion from very well-known personalities about what "clean code" is, and also suggests we apply the Boy Scout Rule (Leave the campground cleaner that you found it) to our code. The following chapters present practical advice about how to do this cleaning (or even better, how to avoid the mess in the first place).

The suggestions presented in the book (meaningful names, pertinence of comments, code formatting, etc) may sound very familiar to any experienced programmer but they are presented with such a level of detail and with very illustrative examples that it is almost impossible not to learn valuable things chapter by chapter. All the examples are in Java, but the guidelines they illustrate can be applied, in most of the cases, to other languages.

The most challenging chapter to read (but also a very valuable one) was the Refactoring of the class SerialDate (from the JCommon library). It is a real-life example and the author shows step-by-step what it takes to do refactoring. The last chapter, "Smells and Heuristics" makes a very good closure presenting in categories and in a condensed way, potential problems and suggested ways to solve/mitigate them.

I enjoyed reading this book and after finishing it, I decided to apply the Boy Scout Rule. I took a module written in a procedural language and not only managed to improve the clarity of the code, but also reduced the number of lines from more than 1,100 to 650. The next person to touch this code will certainly be happy to deal with cleaner code!

When most people hear the term "bad writing" they understand the term: Confusing, inconsistent, rambling, big words used incorrectly.

In fact, we have lots and lots of educational programs designed to teach grammar, composition, journalism, and fiction. Master's Degrees in the subject, even.

But for software development we seemed obsessed with "architecture" (whatever that means), process and patterns.

In this book, Bob Martin takes a specific stab at what good code looks like. He provides rules, examples, and even sample transformations.

It is not an easy book. If you are a new developer, you can invest a lot of time and energy into really absorbing the concepts and practicing them yourself. If you are more senior, you may disagree, you may struggle, you may toss the book in a corner and yell at it ...

But then you'll pick it back up again. And you will be a better developer for it.

One thing that I struggle with about the traditional CS cirricula is that so little attention is spent on maintenance, which is the vast majority of actual development time. This book presents an aesthetic and the skills to write maintainable code. If you teach software development, you'll want to use this book in your courses.

Student, Journeyman, Master, or Instructor - A book like this belongs on your bookshelf. Follow the advice in it, or have an explanation why not - either way you'll be a strong developer.

Of course, there are other books in this area. What struck me about this one is the quality of the writing; it is truly engaging and -- a little inspiring. That quality is so rare in technical books that I give this one five stars.

"Clean Code" focuses on how to write "good" code. Where "good" is defined as being easy for others to read and maintain. It's not that I disagree with the definition of "good" here. The quotes are because 'bad" code is easier to identify. Then there is "good" code and really "great" code. The code in this book is what we should aspire to write.

There are three main sections to the book. The first describes principles with examples. I liked this section best including the chapters written by other experts. The third is the actual "smells and heuristics." While they are good, they were so short they wound up being a summary.

The second section is the case studies. Martin warns up front that this will involve a lot of reading code and cross referencing. I had trouble with flipping back and forth between the chapter, rules and an appendix at the same time. So much flipping was disruptive to my train of thought - even with three bookmarks.

Martin is good about referencing other related titles such as "Implementation Patterns." If you haven't yet read "Implementation Patterns", I recommend starting with that title. It's easier reading which is helpful when newer to a topic. Also while both books are very good, I liked "Implementation Patterns" better. (see my review on that title for why)

The actual content was excellent. The book only loses a point for the logistical issues in reading it.

In response to the "Don't get the Kindle version" review -- the problems appear to be resolved now. It looks fine on my Kindle 3 (aside from using proportional fonts in code examples, but this isn't too bad once you get used to it). Also, as many other reviewers have pointed out, this is an excellent book. I really wish all of my colleagues, predecessors, and managers had read it. My job would be so much easier and more enjoyable if they had.

Because I am passionate about coding, I expected to love "Clean Code", by Robert Martin. I've heard Martin speak on software development, and he is terrific. If you ever get the chance to listen to a presentation by him, do not miss it. Likewise, Martin's articles and essays are excellent, even ground-breaking. Many should be required reading for anyone who styles him or herself as a programmer, developer or software engineer.

Perhaps it was the curse of high expectations, but I found this book to be a disappointment.

The book is apparently a joint effort. Some of the chapters by other authors seemed a bit light. In particular, the only notable recommendation from chapter 11, "Systems," is to consider aspect-oriented architecture. Not only is this an unrealistic option for most developers, but for those of us not implementing application frameworks, it is probably a very bad idea. This chapter also cavalierly dismisses the strategy of lazy evaluation as a "little, convenient idiom", and should be avoided so that there can be a clear separation between construction and implementation tasks. In my experience, no one considers lazy evaluation unless forced to by circumstances (e.g., order of class initialization; performance considerations for interactive systems, etc.). Certainly separation of object creation and execution is a worthy goal, but sometimes requirements get in the way of ideals.

For the most part, Martin's specific recommendations for improving code are solid and should be followed, but there are several that strike me as wrong-headed. For example, for the sake of reducing visual clutter, Martin advises us to forego using the keyword "final" in variable and class declarations, and goes on to say that his unit tests should detect any errors that the final keyword would have prevented. The problem with this argument is that it could excuse any number of bad programming practices; in my opinion we're better off using "final" and living with the clutter.

On a more minor issue, I was disappointed to see that Martin has changed his mind on vertically aligning variables and expressions. My experience is that this practice makes code much more readable. In fact, I had some difficulty picking through his unaligned code to find variable names.

Also, unlike Martin, I think that some minimal encoding of type in a variable name is helpful - I like to be able to differentiate scalar values from objects at a glance.

Another surprise is Martin's claim that the optimal length of a method is a single line. In most cases, this is just wrong: with the exception of "getters" or obvious translations between the problem-space and solution-space (e.g., "bool noIssuesArePending() { return issueList.empty();}"), I find it incredibly confusing to dig down to one method only to find a one-liner referring me to another.

Sadly, it is not just in minor areas that the book disappoints. Perhaps its greatest flaw is that Martin's example of well-written code violates his own imperatives (viz., to the extent possible, the purpose of a routine or program should be clear, so much so that the implementation seems simple and natural, perhaps even trivial). As I dug through Martin's code (and it required digging), the main question I kept asking was what on earth was going on, and what function the various subroutines could be doing. It was a program that I had to read end-to-end three times before I could understand any individual method, which would bode poorly for code maintenance.

Appendix A, on concurrency, is another serious disappointment. Well into it the author, Bruce Schuchert, states that for a program with two steps (S1 and S2), concurrently executed by two threads, the possible sequences of operations include (S1, S2, S2, S1).

This is wrong; that sequence is impossible. If a thread executes S1 and the next executed step is S2 then step S2 must have been executed by the same thread. At that point, the only possible way to end the sequence is for the other thread to complete S1 and then S2.

After I found this error, it hard to work up much enthusiasm for slogging through the remainder of the chapter. I understand
that a book without errors is probably as rare as a bug-free program, but this seems like an unfortunate mistake to appear in an in-depth treatment of threading. (For a correct analysis of the surprising variety of ways that two threads can execute a program with two steps, see "The Art of Concurrency," by Clay Breshears, Chapt. 3, Figure 3-1.)

If you are serious about coding (and you would not be reading this if you weren't), then "Clean Code" is probably worth a skim, but it is by no means the book I had hoped it would be.

In the introduction the author mentions several times this book is really hard work and just getting through portions of it should take many days. He says it's not a "feel good book" you can read on an airplane. He also points out it's a prequel to his 2002 book Agile Software Development.

This book *is* hard work. It's much like a textbook with lots of homework problems. And some of the problems you're expected to solve seem to be needlessly complex or even obtuse in terms of getting across the desired concept--like a college professor trying to challenge even the best students.

This isn't supposed to be a book on how to figure out poor or tricky code, it's a book on how to write clean code. If you like the challenge of figuring out other's code, you'll likely enjoy this book. If not, you might be better off with something like Code Complete 2 that takes a more practical and readable approach.

My second disappointment is some of what's in this book seems dated. The author himself says the book is a prequel to his 2002 book, and some of his perspective is clearly from that era. As we all know, software development is constantly evolving. Many things that were considered "best practices" a decade ago have been abandoned or improved today. But Uncle Bob (Martin), who's been writing software since the 70's, seems to have a romantic attachment to some outdated concepts. Again, Code Complete seems to have done a better job staying current.

I'm also not especially fond of the writing style and perspective. The author seems to put writing software on par with being a world renowned master architect or artist. His implication is we should all strive to have every line and brushstroke be perfect and create works of art to be deeply admired by anyone who sees them. I think the realities of the world today make such an approach impractical.

Few of us have the luxury of treating our code as something we can take many years refactoring and perfecting before releasing it. This book does little to help someone balance the cleanliness of their code with outside requirements they have little control over. Martin simply suggests developers need to stand up to management and make their own demands. That's often not realistic. Most people writing code are more like the guys who frame houses, install the plumbing, etc.--not the master architect who drew up the plans. We're required to be as productive as possible.

Martin acknowledges his ways are not the only way but he often implies they're the only *correct* way. To me this seems arrogant. He reminds me of a department head in college--someone who's above everyone else. Personally, I do better with books where the author come across as more of a peer than a self-proclaimed guru.

So, in the interest of full disclosure, I haven't made it through this entire book and probably won't. I've read The Practice Of Programming, The Pragmatic Programmer, Code Complete 2, and I just can't find much practical in Clean Code that adds to what's in the other books. If you have read any of these, this book might be a waste of money unless you really enjoy the challenge of wading through code examples, you teach programming, or you're especially fond of the author and his idealistic perspectives.

"Clean Code" informs developers how they can write code that is more readable and maintainable.

The first section of the book covers identifying confusing code and rewriting it for topics such as variables, classes, and concurrency algorithms. These chapters contain snippets of code before and after some thought was taken to make the code's intent clear. Although the examples are all in Java, the principles could be applied to most languages.

The second section contains case studies of taking source code and applying the ideas from the first section to contrast how much code can be more readable and maintainable. It was difficult to flip back and forth between pages to follow the differences, but the case studies succeed in showing iterative improvement in the source code.

The final section is a short summary identifying when code might need re-factoring to improve readability.

I believe "Clean Code" does a great job showing how code quality improves when someone writes or rewrites code with the will to make it better. Before reading this book, I applied some of the ideas from Robert Martin and the other authors, but after reading the book, I learned a lot how to write better code that I apply to my programming today.

Just as Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition shows how poor web usability can confuse users and how to address it, "Code Clean" shows how poor code readability can confuse developers and how to address it.

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)

First Impressions

I began reading this book with a couple of concerns. First, all the code examples were written in Java, and I haven't written much Java in the last couple of years. Secondly, the books seventeen chapters were written by seven different authors. In my experience, most books with this many authors are at best a collection of uneven chapters, or even worse a morass of redundancy and contradictions. In the end, neither of these concerns proved to be a problem. Instead they demonstrated the authors' point - that clean code is readable code.

The book's main premise is that clean code results from paying attention to the small details (details that are often overlooked in an effort to meet a deadline, or simply get the code working). This overriding theme allows for a seamless blending of each author's contribution into a cohesive readable whole. Where contradictions did occur, the authors not only acknowledged them, but successfully argued that they resulted not from conflicting ideas or approaches, but from differences in priority. Even the high quality of the editing, and typesetting silently reinforce this attention to detail and professionalism. Most computer books have several technical, typographical and grammatical errors in every chapter. I found only a single one in this book (several hundred pages in). This attention to detail silent reinforces the lessons presented in this book.

What's Inside

The book is divided into three parts. Part I (chapters 1-13) demonstrate what makes up clean code, what it looks like, and how to begin creating it (by picking better names, properly using comments, properly structuring your code etc.). By organizing this section into a series of small chapters the reader is able to begin applying these lessons from day one.

Part II (chapters 14-16) contains a series of case studies demonstrating how to apply the rules and guidelines from part I. These case studies show that like refactoring, cleaning code is an iterative process. One that should be undertaken at every opportunity, because all code no matter how good can be improved.

Part III (chapter 17) is a knowledge base. This section documents the rationale behind every change made to the code in the case studies. This final chapter shows that clean code requires both the ability to make the changes, and to know why they were needed.

Final Impression

No book alone can make you a better programmer, anymore than a screwdriver can make you a better carpenter. However, if you have the discipline to go beyond simply getting your code to work, and begin writing clean code, then this book can help you to become a better more professional programmer. If correctly applied over time, it can even serve as a bulwark against an increasingly fragile code base comprised of hacks, kludges and quick fixes. This book not only taught me how to improve my code, but demonstrated that its principals are both timeless, and language agnostic. I would recommend this book to anyone who writes code.


Clean Code A Handbook of Agile Software Craftsmanship
By Robert C. Martin
Published by: Prentice Hall
isbn: 0-13-235088-2

Books like Clean Code are much more worthwhile than any "Learn the latest hyped technology API now!" book. Clean Code will never be outdated while specific technology books have a shelf life of six months to two years.

Whatever language or API you are working in, you will find solid advice in Clean Code on how to write code that is effective and that you can take pride in.

You may disagree with some of Martin's specific advice, but you will still learn a lot by understanding his reasoning for a particular practice.

Bob Martin is a wonderful writer, which is a rarity in the technical book field. His prose is as concise and effective in communicating his thoughts as the code that you will write if you take the time to learn from the master.