In this book, “Uncle Bob” teaches us how to write clean (good) code. But why is clean code important? Because, to summarize the author’s philosophy, you either pay now or pay later, but you will eventually have to pay. You pay later when you decide to write ‘quick and dirty’ code at the beginning of a project, which could allow you to be faster (at the beginning) and fulfill some deadlines (at the beginning); but in the long run, modifying or maintaining that code is a slow and painful process. On the other hand, paying now is putting the effort to write good code from the beginning which allows you to be more efficient in the long run.
For Bob, clean code is important because bad code slows everyone down (e.g. you, your team and your company). Bob mentions that he had seen great software companies going down because the codebase became impossible to work with (usually because of rushing to market at the beginning). He mentions that one of the symptoms of having bad code is that: every new feature breaks the existing code in several ways; people cannot rely anymore on what functions in the code-base say because calling functions has strange side-effects; every upgrade is painful because dependencies are spread all over the code etc. He claims that whoever has been a programmer for more than 3 years know what is to be slowed down by someone else ’s code.
Bob mentions that defining clean code is not easy so he consulted several ‘gurus’ in computer science to share their thoughts on the matter. They mentioned that clean code is: “elegant”; “efficient”, “easy to maintain”; “performant”, “simple and direct”; “read like well written prose”; “can be read and enhanced by other than the original author”; “unit and acceptance tests”; “looks like it was written by someone who cares”. So clean code is not code decorated with #’s and *’s; clean code is good code, clean code is professional code.
Bob then takes the reader throughout all that he thinks constitutes clean code and how to write it yourself. He starts from the bottom-up: how to name variables and functions! His recommendation: “You should name a variable using the same care with which you name a first-born child.” Then he teaches you how to make functions correctly: “Functions should do one thing. They should do it well. They should do it only”. He also mentioned comments: “The proper use of comments is to compensate for our failures to express ourselves in code”.
Afterward, he teaches you some basic design concepts that make your code clean. For instance, he discusses the differences between objects and data structures: “Objects hide their data behind abstractions and expose functions that operate on the data. Data structures expose their data and have no meaningful functions.” He also mentioned the Law of Demeter: “a module should not know about the innards of the objects it manipulates”. Example: do not try these type of chains (Bob call them train wrecks) . And he spent considerable length praising and urging us to adopt Test-Driven Development.
Uncle Bob finishes with the (expected) list of “Smells and Heuristics”: This is a list of more than 60 rules and good practices that you can start using to improve your code. He divides them into four groups: comments; environment; functions; general; java specific; names and testing.
I would recommend the book for everyone who likes programming. I think all of us want to excel in our coding skill but sometimes we just don’t know how to improve. This book provides an excellent guideline to help you get started. It is also useful because you will learn several basic computer science concepts that are going to help you fill knowledge gaps. For example, for me it was very useful when Bob shared the differences between Object-Oriented programming and Procedural Programming; the rules for handling third party code and his discussion about concurrency.
