A few months ago, me and colleague Jonne Kats had a discussion on whether or not to refactor a single- line non-intuitive expression in a properly named method. Just for the sake of the argument, I was against this particular instance, and he was in favor of many very small methods. I felt it was more a matter of personal preference, but he challenged me by referring to the book Code Complete , written by Steven McConnell. Obviously, I took on this challenge and read the 2nd edition.
The 2nd edition of Code Complete holds about 900 pages, but is definitely worth the read. The first 200-250 pages deal with general considerations for building high-quality software, followed by an equal amount of pages dealing with the typical interpretation problems that have made coding standards so popular. To me, those chapters provided additional food for my enthusiasm towards coding guidelines. Especially the stuff dealing about naming classes and members helped me gain additional arguments for making developers understand their significance. The remainder of the book covers almost every noticeable aspect of software development. Some chapters are very technical and deal with topics such as debugging practices, performance tuning, productivity tools, but others are actually very high-level and cover system integration and configuration management, project management, and management involvement in general,
The book uses examples written in VB, C++, Java and occasionally in C#. That was quite nice because even though I'm a former C++ developer, I forgot about the peculiarities of C++ and how much cleaner C# really is. Consequently, some of the examples were not really applicable to me. And since I've already spend a good deal of my career on coding, layout and design guidelines, I skipped most of the chapter covering code layout. The chapters on debugging and programming tools were a bit obsolete as well, because debuggers and development environments have matured incredibly since 2004, the release date of this book.
On the other hand, in spite of its age, the book is incredibly actual. Many of the practices explained in this book are now considered Agile practices. And were it really stands off against all the other design-related books is its extensive use of hard facts. I can't remember reading a technical book that caused me to send a few pages to my direct supervisors or my customer's management team so often. It is full of comparisons and study reports explaining why practices such as automated testing, pair programming, coding standards, and proper naming work so well; Steven did not held himself back on psychological and empirical studies. And the beauty of this all is that it is very lighthearted easy read, similarly to Jimmy Nilsson’s DDD with C# book, and a welcome change to the excellent but very dry Domain Driven Design by Eric Evans.
So what about that discussion with Jonne? Well, as usual when we have a discussion on topics such as this our intentions and goals are the same, but somehow we always differ in nuance. In this particular case, I must agree that replacing the non-intuitive expression with a single-line method was the right advice. That doesn’t mean you have to do that everywhere, just stick to the rule that a method should do one thing, and do that thing right. Just read the book and learn to gain a feeling of what is right from there.
Obviously, reading this book has changed my current shortlist of must-reads a bit: