House construction

A wonderfully practical guide to programming, May 2, 2011

The tragedy for books that become classics is that there are many more people who have heard of them (or perhaps also bought them) than people who have read them. In this case, the fact that Steve McConnell’s “Code Complete” is approximately 900 pages long doesn’t help, either. Even so, this is a book that not only deserves to be read, but also rewards multiple readings.

The Good: McConnell deserves credit for writing the first (and only?) readable encyclopedia of best practices on software quality, covering topics such as how to build classes, use data and control structures, debug, refactor, and code-tune. Yes, it would be nice if the book was updated to include substantive material on languages like Ruby or Python (cf. p. 65, Python “also contains some support for creating larger programs”) but, in the words of Gertrude Stein, “Not everything can be about everything” — though Code Complete does come pretty close. This book contains an astonishing number of practical points on a variety of topics. Here is a quasi-random selection: a) don’t use booleans as status variables (chs. 5, 12), b) when you feel the need to override a function and have it do nothing, don’t; refactor instead (ch. 6), c) when choosing variable names, avoid homonyms (ch. 11), d) if you decide to use a goto, indenting your code properly will be difficult or impossible (ch. 17), e) trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often (ch. 22), f) make your code so good that you don’t need comments, and then comment it to make it even better (ch. 32), and finally the oft-repeated g) you should try to program into your language, not in it (ch. 34). McConnell also sprinkles the text with classic words of wisdom, e.g. “The competent programmer is fully aware of the strictly limited size of his own skull” (Edsger Dijkstra), “Never debug standing up” (Gerald Weinberg), “Copy and paste is a design error” (David Parnas), “Any fool can defend his or her mistakes — and most fools do.” (Dale Carnegie). It is important to point out that even though this volume is encyclopedia-like, it does have both a sense of humor (e.g. “the encryption algorithm is so convoluted that it seems like it’s been used on itself”) and a clear authorial voice (e.g. “Though sometimes tempting, that’s dumb.”). Another example of the latter: in ch. 33, after quoting Edward Yourdon at length, McConnell adds “This lusty tribute to programming machismo is pure B.S. and an almost certain recipe for failure”.

The Bad: overall the writing is very good, but the occasional infelicity reminds us that McConnell is human (e.g. p. 369 “A loop-with-exit loop is a loop in which”, p. 809 “A program contains all the routines in a program.”). In a technical book of this breadth, minor mistakes are bound to creep in. For example, in ch. 10 McConnell mentions the different possible levels of a variable’s scope in C++, and then adds that in Java and C# one can also use namespaces, thus effectively ignoring the existence of the namespace concept in C++ (which is baffling, given that he then discusses precisely that topic in ch. 11). Another example, this one more serious, is McConnell’s recommendation that you should use a pointer – not a reference – if you want to pass by reference in C++ (ch. 13), something which is contrary to C++ best practices (see e.g. Sutter & Alexandrescu, “C++ Coding Standards”, Item 25). A less technical point: in ch.2 McConnell criticizes Frederick Brooks for writing (in 1975): “Plan to throw one away; you will, anyhow”. I found this to be bizarre, given that in the 1995 edition of “The Mythical Man-Month” Brooks states in no uncertain terms that he has changed his mind on this: “This I now perceive to be wrong” (p. 265). Given that Code Complete 2 was published nearly 10 years later (in 2004), criticizing Brooks for his publicly repudiated former opinion seems improper. On a different note, although some of the on-line accompanying material is fascinating (e.g. the links to the original Dijkstra and Lawrence articles in ch. 17) many of the links are just electronic versions of McConnell’s checklists or bibliographies, while some are simply disappointing. To name only a couple of these, as of this writing the link on p. 856 on the economics of XP is a dead link, while the one on p. 76 is downright embarrassing (it links to a google search for “emergent design”). Finally, even though the book has a dedicated website, no list of errata is provided there. If you dig deeper, you can find one on the O’Reilly website, but that is woefully inadequate, e.g. it contains no information on separate printings.

The most common criticism one hears about this book is that any decent software developer should already know the material covered in it. Ironically enough, this is true. To quote Dr. Johnson: “People need to be reminded more often than they need to be…

Read more

Help other customers find the most helpful reviews 

Was this review helpful to you? 

|

 Comments (5)