Clean Code: A Handbook of Agile Software Craftsmanship
by Robert C. Martin
"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin emphasizes the importance of writing code that is not only functional but also elegant and readable. Central to the book's message is the idea that code should be easy to read and understand, as the time spent reading code far exceeds that spent writing it. Martin argues that clean code is a reflection of professionalism and craftsmanship, advocating for clarity over cleverness. Key themes include the significance of meaningful naming conventions, the necessity of small and focused functions, and the avoidance of redundancy, such as excessive comments. The author insists that comments should only serve to clarify the code when it fails to do so on its own, thereby framing comments as a sign of inadequacy in the code itself. He highlights the "Single Responsibility Principle" (SRP) as vital for good object-oriented design, while also denouncing the practice of leaving commented-out code. Martin further stresses the cost of bad code, suggesting that while it can be improved, it requires significant effort to do so. The book serves as a call for programmers to strive for excellence in their craft, promoting the notion that clarity is paramount and that the best code is straightforward, with minimal dependencies and maximal readability. Ultimately, "Clean Code" is a guide for becoming a better programmer through the disciplined practice of clean coding principles.
30 popular highlights from this book
Key Insights & Memorable Quotes
Below are the most popular and impactful highlights and quotes from Clean Code: A Handbook of Agile Software Craftsmanship:
I like my code to be elegant and efficient. The logic should be straightforward to make it hardfor bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performanceclose to optimal so as not to temptpeople to make the code messy with unprincipled optimizations. Clean code does one thing well.-Bjarne Stroustrup, inventor of C++and author of The C++ ProgrammingLanguage
Truth can only be found in one place: the code.
Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.
It is not enough for code to work.
So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.
You should name a variable using the same care with which you name a first-born child.
A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.
Clean code always looks like it was written by someone who cares.
Of course bad code can be cleaned up. But it’s very expensive.
Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.
Redundant comments are just places to collect lies and misinformation.
It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!
There are two parts to learning craftsmanship: knowledge and work. You must gain the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and you must also grind that knowledge into your fingers, eyes, and gut by working hard andpracticing.
You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.
One difference between a smart programmer and a professional programmer is thatthe professional understands that clarity is king. Professionals use their powers for good and write code that others can understand.
Don’t Use a Comment When You Can Use a Function or a Variable
Programmers must avoid leaving false clues that obscure the meaning of code.
Perhaps you thought that “getting it working” was the first order of business for a professional developer. I hope by now, however, that this book has disabused you of that idea. The functionality that you create today has a good chance of changing in the next release, but the readability of your code will have a profound effect on all the changes that will ever be made.
The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures.
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.
Honesty in small things is not a small thing.
When you see commented-out code, delete it!
First Law You may not write production code until you have written a failing unit test. Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing. Third Law You may not write more production code than is sufficient to pass the currently failing test.
FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.
Whatever else a TODO might be, it is not an excuse to leave bad code in the system.
Duplication is the primary enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity.
SRP is one of the more important concept in OO design. It’s also one of the simpler concepts to understand and adhere to. Yet oddly, SRP is often the most abused class design principle.
A long descriptive name is better than a long descriptive comment.
Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.- Grady Booch author of ObjectOriented Analysis and Design withApplications
