Code Craft, The Practice of Writing Excellent Code by Pete Goodliffe.

Almost any programmer can program. That's more or less the definition of the word. It's pretty rare (but not unheard of) to find a C++ programmer who doesn't know C++.

So what's the difference between a good programmer and a bad one? Usually it's all of the thousands of disparate things that a programmer needs to know to be effective that don't deal with the programming language itself. Things such as design principles, coding standards, testing strategies, understanding of tools, and general development philosophy.

Those are the topics of this book. "Code Craft" won't teach you how to build generic collection classes and optimized tree search routines in Visual Basic or any other language. Instead it focuses on the myriad skills a good programmer uses while building an application. Things such as defensive programming, how to format code, using meaningful names, testing, and source code control. It describes different kinds of programmers and project organizations, and explains how to with the strengths and around their weaknesses. It explains how to write specifications, perform code reviews, and estimate project lengths.

Pete Goodliffe is an experienced professional developer and it shows in the book's right-on-the-money tips. His advice and experiences (as shown in frequent interesting sidebars) agree with mine in almost every way. Of the many tips in this book, the only one I found that I don't agree with is the idea that you should write the fewest possible comments, including only those that are absolutely necessary to explain the code. I've heard this rule proposed by others before and on the surface it makes sense. Unnecessary comment chitchat makes the code harder to read.

The problem with this approach is that the person who writes the comments is generally the same developer who just wrote the code. To that person, the code is extremely easy to understand so very few comments are necessary. Unfortunately to another developer, or to the same person in a few months, the code is not self-explanatory.

I would much rather have some extra comments that make understanding the code easier even if they are not strictly needed to decipher the code. I have seen projects fail spectacularly because developers couldn't understand the code (email me and ask for examples) but I've never seen any problem greater than mild annoyance when the code contained too many comments. If you don't need the comments, don't read them. They're not that hard to ignore.

Even that minor criticism demonstrates why I think you should buy this book: to get different points of view. There are several books available that deal with these sorts of higher-level programming issues including Code Complete, Second Edition by Steve McConnell and Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs by Steve Maguire. They all follow the same general theme but each reflects the personal experiences of the authors. You will almost certainly learn something new in each one. You'll also see where the authors agree (most of the time) and disagree. You'll see what things the authors think are important (as wishy-washy as it sounds, a good attitude and ability to work well with others are common themes) and not so important.

Pete Goodliffe's writing style is fact-filled, easy to read, and downright entertaining. It's perfect for reading on the bus, during the half hour before a meeting when you don't really have time to start writing a new subroutine, and sitting behind the ficus during those awkward cocktail parties that marketing throws to impress customers.

This is a language-neutral book. It focuses a bit on C++ and similar languages but there's plenty of material to benefit developers using any language. Buy it and read it as you have time. If you pick up even a single new tip, it will be well worth the effort.