 | Summaries and Customer Reviews are supplied by Amazon.com | Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.
Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.
What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.
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. 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 the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.
Readers will come away from this book understanding
- 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
This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
|
Average Customer Rating:   Good but could've been better I am a huge fan of "Uncle Bob". 15+ years ago I was reading his papers and learning a TON from them (back then, he was "Robert C. Martin"). Those papers were what he dubs "SOLID" today.
This book taught me some great stuff. One of the best gems is the idea that a function should describe the 3 or 4 steps that are one level of abstraction down from the function's name. Very cool.
However, the book could have been much better. About half of the chapters were merely statements of obvious moral advice. Like, "get plenty of exercise" and "wipe well after using the toilet." The other half were very good because they managed to walk you through some *experience* with some code that *showed* you why you should follow the moral advice.
Plus, the "Systems" chapter was merely a very shallow whirlwind introduction to AOP and a few other concepts. Seriously? To do anything with those concepts, you need a lot more meat than that chapter could possibly give you. So it makes no sense for the chapter to be in the book at all. And the "Emergence" chapter was a big disappointment. I was so excited when I saw the chapter title, because there was potential there for them to do something really special. They could have walked through an example of some code where a design emerged. Uncle Bob states several times in the book that the code does not come out "clean" the first time he types it ... you get it working, but then you don't stop there. Going through an example of that would have been perfect for the "Emergence" chapter. Instead, they just said things like, "Design emerges." Again, shallow moral advice that mostly states the obvious with no additional insight offered.
But don't forget ... I'm talking about HALF of the chapters. The other half were excellent. A lot of wisdom distilled into a few pages. Overall, I give the book 4 stars and recommend it. Read It, Re-read it and Keep it as a Reference If you're a programmer, then you know that most time is spent on maintaining code from existing projects, rather than starting fresh on new ones. And you know that writing good code is sort of an unwritten rule among good programmers, aptly stated by Robert Martin as the "boy scout rule".
If you've ever inherited a project which had lots of bad code, you know the pain and frustration one feels trying to understand it. And of course you'll want to make sure that whoever takes over your source code doesn't feel the same way about your code. To do so, you should get this book. And you should read it and re-read it and keep it as a reference whenever you feel the urge to rewrite your code a little bit better, a little bit cleaner.
There are other books of course that cover some aspects of clean code in various ways, but I feel this book had the most focus and coverage of detailed examples on how to write "clean" object oriented code. For me, it was the equivalent "how to write good code" book for programmers, that "Elements of Style" or "Writing That Works" was for writers in general or writers in business. And the fact that it has some detailed examples on even well known open source code projects, illustrates that there's always room for improvement in writing clean code. This is a very good book with one major caveat I really like this book except for one thing: there isn't much new material here.
This book is a very good summation of:
- Code Complete by Steve McConnell (I recommend the second edition)
- Agile Principles, Patterns, and Practices in C# by Bob Martin
- Growing Object-Oriented Software, Guided by Tests by Steve Freeman
On the plus side, it is well-written, concise, contains a nice balance of theory and practice, and does an excellent job of communicating the principals of Agile programming.
But if you've already bought the other books you don't really need this one. A good book, but not essential Over numerous chapters, and three case studies, Robert Martin covers various patterns, techniques, and practices for writing clean code. He states that one must first write dirty code, and then clean it. That nicely sums up a large part of what programming is about. Robert shows refactorings in progress, and explains how each step makes dirty code a little cleaner. This works well to educate the reader. He also discusses details of error handling, unit testing, variable and function naming, encapsulation, and many other pieces of the programming puzzle.
The final chapter lists and details various code smells and how they can be remedied - essentially the entire book boiled down into one chapter. This chapter is worth the cost of the book.
Clean Code is a useful book; it is not a necessary read to get started programming in X, but it does contain best practices and patterns, making this book good supplemental material. Experienced coders will probably know most of the material already, but the book would be worth a read for the less experienced. Great first chapter, but stop there Chapter 1 presents some very interesting thoughts from some well-known software engineers on what it means for code to be "clean". Good stuff. And there's a good, quick summary of Lean's 5S's, with obvious application to code:
- seiri - sort - organization
- seiton - systematize - tidiness
- seiso - shine - cleaning
- seiketso - standardize
- shutsuke - [self-]discipline
The rest of the book isn't so good. The approach isn't bad - take code and show how to improve it - but the preferred coding style is verbose, and to my mind, often considerably less maintainable than the original code. |  |
Select button not working? 
