I just finished reading the magnificent book Clean Code - A Handbook of Agile Software Craftsmanship. I must say, if I would have a software company of my own, then I would force all my employees to read this book. Make no mistake about it. If you have anything to do with reading or writing code, then stop reading this post and go buy it now! And I mean now!
Still reading, huh?
Something that has been bothering me for a while is the following quote from another excellent book that is written by the same author, namely Agile Principles, Patterns and Practices in C#:
There's no gentle way to put this: in my experience .NET programmers are often weaker than Java and C++ programmers. Obviously, this is not always the case. However, after observing it over and over in my classes, I can come to no other conclusion: .NET programmers tend to be weaker in agile software practices, design patterns, design principles and so on.
Now here comes the part that bothers me the most: he's probably right! Being part of the .NET community, I strongly believe that we have a long way to go. I also believe that applying the principles, patterns and practices as laid out by this book will move us further on up the road.
The fact that all code is written in Java makes no excuse of not reading this book. These principles, patterns and practices virtually apply to every programming language and development platform (which also includes .NET!). There a lot of design principles that I already know and apply rigorously throughout my software writing, but most importantly, I also learned a ton of new things.
The author(s) of this book went to great lengths to offer the reader a good understanding of what clean code is all about. If you want to know the definition of good maintainable code and how it looks like, then this book is for you.
The book is actually a prequel to Agile Principles, Patterns and Practices in C#. The first part describes the principles, patterns and practices of clean code. The second part consists of a number of case studies. In these case studies, the author tries to transform some problematic code into more maintainable code by applying a number of refactorings. The third part exists from a single chapter that contains a list of code smells and heuristics that are gathered from the cases studies in the second part.
This quote from the book, coined by Michael Feathers (Working Effectively with Legacy Code), clearly describes its content:
Clean code always looks like it was written by someone who cares.
How to Care for Code.
But something that is discussed near the end of the first chapter really struck a nerve: The Boy Scout Rule. Originally, this states as "Leave the campground cleaner than you found it". This rule got rephrased and used several times throughout the book as "We should leave the code cleaner than we found it". This is something that I want to live by as a software engineer.
This is probably the best book I've read so far about how to write good, readable and maintainable code. No catch :-).