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

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 codeHow to write good code and how to transform bad code into good codeHow to create good names, good functions, good objects, and good classesHow to format code for maximum readabilityHow to implement complete error handling without obscuring code logicHow to unit test and practice test-driven developmentThis book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.



User review
Please read. Please!
If it's your profession to write code, then you should have this book at your side while doing it. Its in Java but c# developers will get it no problem.

User review
A Quick and Informative Read on Crafting Code
`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.

User review
Clean is a subjective term
The author fails to recognize that creating clean code is a balancing act, so he proceeds to fall off of a couple of big cliffs: 1) Advocating creating a million tiny functions each of which does almost nothing, and 2) Variable and function names that are so long they form detailed descriptions. While its true that with super long names and trivially small functions its possible to write basically self-documenting code, there is a major sacrifice of overall clarity. While each function on its own may be understandable, if you have split relatively simple processing across 6 different functions, you have greatly reduced the signal-to-noise ratio of the overall project. Each function you have created also now needs to have an interface maintained in both caller and function, and in C++ you will additionally need to maintain all of these interfaces in separate header files. There are many cases where this is a worthwhile strategy (re-use of functions, encapsulation of business logic, etc), but the author takes it way past the point where it makes sense and the result is code that is tedious to read, understand, and maintain. As far as the long names go, I personally don't want to wade through 30 character names for every variable or function, since it absolutely removes the ability to take something in at a glance (this name explosion seems to be an unfortunate trend in the java world). Lets be realistic; the vast majority of variables and functions can be effectively and clearly named with two words instead of a run-on sentence for a name. There are other questionable patterns he advocates, such as redundant Interface declarations for creating a class: E.g. the base interface might be MyWidget, and the instantiated class is named MyWidgetImpl. If you don't NEED polymorphism this is only going to create confusion, and if you DO need polymorphism then using a generic suffix of `Impl` is pretty much unhelpful. I would give this book a miss, doubly so if you're not working in java.

User review
Code improvements of the third kind
Let's get this out of the way right now: There are a LOT of books out there about improving your programming style. Even books that aren't about coding style tend to have at least a chapter or two on it, or pepper the text throughout with capsule suggestions on good style.

In my experience, these books fall into three categories.

The first category is the `safe` category. It offers obvious, unchallenging homilies about exception safety and RAII. It'll make you feel good about yourself because you're already doing most of the things; and the ones you're not, you will have already thought about doing and have good reasons for not doing. This first category does not improve the coding style of already decent programmers.

The second category is more crotchety and conservative. This is the camp that would have you never have multiple returns from functions, and document every single function with a ten-line preamble comment (more if the function actually does anything). This type is more daring, and may have some good suggestions, but it's difficult to find them because they're hidden in reams of bad suggestions which can be discarded without much thought. This category is also `safe`, not because it tells you things you already know, but because it tells you things you can ignore.

The third category is this book. It's not a safe book. Many of the suggestions will mystify or anger you. They'll sound ridiculously Panglossian, impractical for any but the most trivial of codebases. Others will strike you as trivially obvious, which will irritate you, until you realize that you're not following them, which will irritate you more. This is a book which will change you, for the better.

User review
Fulfill my expectation
I would have given it 5 stars if I didn't read the Code Complete 2 by Steve McConnell.
This book is clear and concise for readers of all levels of programming skills.
I would recommend Code Complete 2 along with this book