This book is very much in the spirit of “Code Complete” in that it talks about software construction at a pretty low level. The book is written from a Java perspective, but easily most of the ideas transcend a particular language. It is very rare to come across books which have the potential to completely change the way a person thinks about writing code. This is one of those books.
One of the best things about this book is the hands on approach to making the code clean. It is one thing to talk about how to make code better, but it is another thing to use real world code and show how it is transformed.
- Great explanation of why clean code is important.
- Very detailed information on choosing good names.
- Excellent advice on function size and parameters.
- Very convincing chapter on why comments are usually bad vs writing code that expresses its intent.
- Unit testing advice, how to keep tests clean.
- Excellent coverage of concurrency problems and solutions.
- Real examples of refactoring and making code clean from real projects.
- Nice section on code smells and heuristics.
Honestly, not much here at all… the only thing is a chapter on formatting which I found not that important, since most of us use auto-formatting rules in our IDEs.
What I learned
It's hard to pick out all the little pieces of “ah ha” moments when reading this book, but here are a few in particular that stuck out to me. I may have known some of these things, but reading them in print made them so much more clear and concrete.
Methods should try to not have parameters. The less parameters the better. I kind of already knew this, but in this book it is made really clear why having 1 parameter is so much better than having 2.
Try not to overload methods taking different parameters. When looking at some of the code examples here, I could very clearly see why having another method was better than an overload.
I was relying on getter and setter methods in my code too much. I learned that I should be thinking of a way to not have to use getter and setter methods by making the class do the work or moving parameters inside the class.
I was thinking the more Java Doc or NDoc the better, but after reading the section on comments, I realized that having that hard and fast rule is not really good. Now I am only going to use Java Doc or NDoc where it actually provides information, not just as a rule.
Don't return null. This seems obvious, but I realized that instead of having to try and deal with null parameters, a much better strategy is to just never return null in your code so that you never have to try and deal with null.
Several bits about concurrency. It was really interesting to see why concurrency issues can occur from a byte code viewpoint. I learned about a few places I didn't realize that concurrency issues could occur and some good techniques for putting concurrency problems into a single class and not letting them leak into the entire application.