─── “It is not enough for code to work.”
Clean Code by Robert C. Martin is a quite popular book among developers. You have good chances to hear of it wherever two or more programmers gather in one place, whether it's an office kitchen or a hackathon.
I decided to read the book when I had already been practicing programming for a while. At that time, my main motivation was to strengthen my experience with a better theoretical understanding of software development as a craft. Clean Code turned out to be the best possible choice. So here is my brief review of this book along with some key lessons I’ve learned from it.
Quality code is easy to read
The book covers practically all aspects of creating a good program, from writing names and comments to organizing and designing classes. R. Martin doesn’t deny that poorly written code can function as intended. But it usually comes at the cost of many hours of additional work that you or another developer will need to do later. That’s why it’s so important to ensure that the code is clean from the very beginning.
But the book isn’t just a philosophical or motivational piece, it’s stuffed with a variety of practical tips and recommendations. The main idea behind most of them is that clean code should be easily understood not only by its author but also by any other programmer who starts working on a project. For example, R. Martin suggests:
- avoiding any complexity in code
- choosing only meaningful descriptive names that don’t cause any ambiguity
- creating code that explains itself
- rewriting bad code instead of commenting it
- leaving comments only when they’re necessary (e.g. as an explanation of intent)
You should always follow a boy scout rule
Boy scouts always leave the campground cleaner than they found it. According to Clean Code, this rule also applies to programming. R. Martin encourages developers to take action on detected problems rather than just ignore them. He compares leaving a mess in a code to littering and claims that paying off technical debt is absolutely necessary to prevent degradation of a system.
R. Martin also insists that developers need to read a lot of code to master their skills. That’s why the book contains a chapter consisting of case studies that are also practical exercises for readers. These real-life examples allow programmers to better understand what the author is talking about and why he recommends doing or avoiding certain things.
Cleaning code “on the fly” must be a common practice
The main goal of R. Martin was to teach developers to define bad code and clean it while writing a program. In the book, he provides a categorized list of code smells with detailed explanations of how to detect and get rid of them.
For example, he claims that such characteristics as rigidity (when a change to the code causes many other changes), fragility (when a change to the code causes various breaks in a program), and unnecessary repetitions may be the indications of deeper problems. Once they’re spotted, a programmer should try to get to the roots of the issue and address it as soon as possible.
So you can use Clean Code as a comprehensive guide on refactoring. It’s also a nice idea to reassess your existing code based on the list of code smells from the book. This will help you not only improve a software product but also rethink your approach to programming.
Wrapping-up
Mastering programming skills requires a lot of practice so reading Clean Code won’t immediately make you a better developer. But if you start applying recommendations from the book in your working routine, the results will definitely become noticeable over time. So I can totally recommend it to any programmer who strives to grow professionally and become a true craftsman of software development.
P.S. All examples provided in Clean Code are written in Java but, in most cases, it doesn’t affect their value. I believe any developer will have no problem understanding the main concepts outlined in the book.
