General Information
The book is written by popular programming evangelist and experienced developer Robert Martin. It’s a book about how to write cleaner and more accurate code. Let’s briefly look through it.
Brief Chapter Overview
The first chapter is purely theoretical and a bit dry. It discusses the importance of writing good code and how maintaining bad code becomes more and more expensive each month — in terms of both money and time.
Next, the author talks about how to better name variables: that they should convey the programmer's intention, and when reading a variable, it should be clear what is stored and what type of data it is. He advises to avoid abstract names like List, Data, etc. Method and class naming is also briefly mentioned — although this topic is covered in more detail later. There are quite a few tips, most of which are logical and sound. On the one hand, it’s a rather basic and obvious chapter; on the other — it might be very useful, especially for beginners.
Then come functions. This is where the more controversial topics begin — like how many lines a function should be or how many parameters it should take. The answer, of course, is: the fewer and simpler, the better. But in practice, it’s not always that easy. The author also makes a solid point that a function should do only one specific thing. For example, a single function should not both calculate the average and print the result. Classic SOLID principles. The chapter also covers tips on handling conditions (if, else, switch), loops, try/catch blocks, and of course touches on function naming and the DRY principle (don’t repeat yourself).
After functions comes another hot topic — comments: when and where they should be used, and when they are unnecessary. Legal, journal, and some other types of comments are explained by the author with examples of when they are truly appropriate.
If you think comments are a controversial topic, what about formatting? That’s the next short chapter. And no, it’s not just about tabs and spaces — the chapter is much more informative than that. The author even includes various diagrams.
"Working with Objects and Data Structures" is the title of the next chapter. Abstraction, data asymmetry, the Law of Demeter, DTOs, Active Record, and other topics are covered briefly here. The coverage is more surface-level, assuming the reader is already familiar with these concepts.
Then comes the chapter on error handling. Most examples in the book are in Java, so you won’t find error handling in the Golang style (via if statements). The focus here is on try/catch blocks. Earlier we talked about formatting — now it’s about when, where, and how to use exceptions.
The next chapter, “Boundaries,” is less about code itself and more about architecture — specifically module composition and usage. It’s a small section, so if you’re interested in Robert Martin’s views on clean architecture, it’s better to refer to his dedicated book on that topic.
Then we move on to “Tests.” A few words about TDD, followed by a brief explanation of what a test should look like. It’s a short and not overly informative chapter. If you’re interested in testing, I can recommend a great book and will likely review it soon.
Next — “Classes.” Again, if you look at classes as part of code improvement (which Uncle Bob does), the material here may be sufficient — assuming the developers are already familiar with OOP. Otherwise, if you want a deeper understanding of object-oriented programming, this section might be lacking or even difficult.
The following several chapters focus on architecture again. No, it’s not the typical layered architecture Martin recommends in his other book. These chapters are more about basic principles. The first one is more about block diagrams than actual code. Some patterns are mentioned briefly — abstract factory, dependency injection, proxy. Overall, these chapters are good and informative.
Then — a chapter on multithreading. It’s mostly theory rather than practice: there’s not much code, and the coverage is fairly superficial.
The next chapters are about code refactoring, with examples from Robert Martin. And here, unlike in some of the previous chapters, there’s a *lot* of code. First, the author refactors a command-line utility, then a couple more Java libraries/classes from well-known developers. Even in their code, Martin finds flaws — which, to me, sometimes seem more like nitpicking than real refactoring. After all, that code worked and had high test coverage. The key message of this chapter: writing working code is not enough — it must also be easy to maintain, otherwise it will become a nightmare over time.
The final chapter is a kind of summary, made up of advice that includes everything discussed earlier: from comment guidelines to working with functions and tests.
Conclusion
Pros
- The book has a well-thought-out structure. It consists of 17 chapters, each one building on the previous. In other words, just like how people learn programming from basics (variables, comments) to more advanced topics (functions, classes, async, etc.), the book follows this pattern — which is intuitive and convenient.
- Most of the advice is genuinely useful and logical. Some readers will discover a lot of new insights, while others — almost none. It all depends on personal experience.
- The book includes illustrations. There aren't many, but those that are present follow a consistent style, which is a nice touch.
Cons
- You shouldn’t follow all the advice blindly. There were at least a few, if not many, “tips” I didn’t fully agree with or disagreed with entirely.
- The book isn’t short — a bit over 450 pages. Reading long books can be challenging for many.
- The refactoring examples (adding/removing lines) could’ve been presented better. Currently, changes are marked only with bold (added) and strikethrough (removed); a git-client-like style would’ve been more familiar to many.
- Examples are in Java. I had no issue with that, but for those unfamiliar with the language, this could be a downside.
- I got a 2010 edition. There may be newer editions out there. The one I read felt a bit outdated. It could definitely use an update and some additions.
Final Verdict
This book is rightfully considered a bestseller in the field of code development. It’s worth at least skimming through — ideally, reading it carefully. If you don’t have the time or desire to read the whole thing, I recommend checking out the chapter summaries and the final chapter with general advice. After reading, it’s useful to discuss the approaches and recommendations with your colleagues — because blindly following Robert Martin’s advice might not only be inappropriate, but also incorrect in some cases.
