Code Complete

The focus of Code Complete is software construction, i.e. the coding part of software development. As Steve McConnell notes in the preface, "construction is the only activity that is guaranteed to be done". You can skip almost any step (requirements, testing etc), but if you don't write any code there is not going to be any software.I bought my copy of the first edition of Code Complete in 1997, and I was immediately fascinated. I had never read anything like it before - a book that concentrated on the actual writing of the code. For example, it had a whole chapter on if- and case-statements, and another chapter on the naming of variables. I had no idea there was so much to learn about these seemingly straight forward activities. It was immediately useful to me, and I started to apply as much as I could of what I learnt from it.Although it concentrated on coding, it covered a broad spectrum of activities around coding, from requirements and design to testing, debugging and optimization. It also had a great reference section with suggestions of further reading in the area of software engineering. This became my starting point for finding lots of other good books to read, like Peopleware: Productive Projects and Teams (Second Edition) and Programming Pearls (2nd Edition).So this summer I decided to re-read this seminal book, partly to see what's new in the second edition, and partly to see if still think it is such a great book.To answer my own question - yes, it is still the number one book on writing code. It is near encyclopaedic in its coverage of the nuts and bolts of programming. There are chapters on the naming of variables, on organizing straight-line code, on conditionals, on loops, on lay-out, on good commenting and on how to write good methods.In it, there are frequent references to scientific studies that support the advice given in the book. For example, how long should variable names be? Instead of just giving us his opinion, McConnell summarized the findings of several scientific studies on the subject.Each time there is reference to a study, there is a little "hard data" symbol in the margin. There are other symbols in the margin as well, "Coding Horror" for code examples of what not to do, and "Key Point" for, well, key points. The margin is also used for cross references to other chapters, and for quotes related to the subject discussed. For me, this works really well. It is both useful and makes the text easier to read. In general, the book is very well laid out.Some of my favourite advice from the book (all of which I remember from reading the first edition) are:Chapter 7.1 Valid Reasons to Create a Routine - for example: Reduce complexity, Introduce an intermediate understandable abstraction, and Avoid duplicate code (there are 6 more valid reasons in this chapter). The second part of the chapter is called Operations That Seem Too Simple to Put Into Routines and contains a great example of why it can be good to put even a one-line calculation in a routine - the code becomes more readable, and small operations tend to turn into larger operations.Page 172 (and 264 for variables) Use opposites precisely. When naming "opposite" methods and variables, be careful to use the correct pairs, like add/remove, begin/end, create/destroy etc. This makes the relationship between them clear and obvious.Page 433 Break complicated tests into partial tests with new boolean variables. This is such a simple thing, but it makes the code a lot more readable.Page 754 "Make the incompleteness of a statement obvi". For example, when breaking up a logical and over two lines, end the first line with && - that way, it is clear that the statement continues on the next line.Even though the book truly is great, there are a few things to complain about. In the first edition, the chapters on layout and comments came right after the chapters on the different control structures. But in the second edition, these two chapters have been moved further back. To me, that doesn't make sense, since they too are related to how you actually write your code. Now there are chapters on testing, debugging, optimization and refactoring in between.And talking about refactoring: while this is an important subject, I don't feel the chapter on refactoring is particularly good. This chapter is new in the second edition. The summary of refactoring is OK, but a good part of the chapter consists of just listing different kinds of refactorings.Overall though, the second edition is a nice face lift. The code examples are now mostly in Java, C++ or Visual Basic (in the first edition they were in Pascal, C or Ada). But since all the major themes of the book were already present in the first edition, it does not make a big difference if you happen to read the first edition instead of the second edition.Code Complete is thick - 862 pages (not counting the bibliography and index). If that feels like a lot to read, then I suggest you start by just reading one or two chapters, for example "Using Conditionals" or "Layout and Style". They (and pretty much any chapter in the book) can easily be read without first reading the preceding chapters, and these will give you a sense of what you can expect from the other chapters. Even if these are all you read, you will still get a lot of value from the book.However, if you are a programmer and care about how you write code, you owe it to yourself to read the whole book. It is considered by many (including me) to be the best book available on programming, and it will almost certainly make you a better programmer. Highly recommended.

I finally decided to invest the time in reading Code Complete after hearing well-spoken computer scientist Greg Wilson sing its praises on a Ruby Rogues podcast episode. Greg felt this book should be the core textbook in every undergraduate CS program although he will buy you a beer if you can find it in one. Greg says that Steve McConnell has practically memorized every significant industry paper written in the last 30 years. That knowledge shows in this book and its an especially great read for those who want hard data to back up claims.Even though Code Complete is arguably the most recommended programming book in the industry, I get the sense it is underappreciated by most folks who work in my ecosystem (open source/ruby/linux/etc). Whether that is true or not, here are a few reasons why I think it may be the case:1.) "It is a Microsoft book and uses Visual Basic in some of the examples." Well, after reading the book cover to cover, I don't feel either of these were a problem. McConnell makes the conscious choice of using multiple programming languages throughout the book under the rationale that a good software craftsman should be comfortable parsing somewhat unfamiliar syntax. He even points out an instance or two where he feels a VB implementation decision is superior to what is found in most programming languages. Don't get me wrong, nobody is saying VB is a great language, but to write off the book because of the connection would be foolish.2.) "Its a book about things I already know. I found a bullet point summary online and didn't have any 'aha' moments". My response to that is this: While I can't point to any particular section that will be mind blowing for most developers, I found myself transformed into a much better programmer while I was reading this book. Furthermore, in 2012 Sandi Metz released a book that has become an undisputed classic in the Ruby community. It turns out that a lot of the good OO design practices taught in her book appeared in Code Complete many years earlier in language-agnostic form.3.) "Its almost 900 pages". I admit--the length of the book is a drawback. However, when you examine the contents, it is clear that McConnell is attempting to cover more ground in a single book than anyone before or since. It is also pleasant reading--not light reading by any means, but its not stereotypical textbook reading.Something I did not know about this book in advance is that it is an excellent gateway book for the software engineering classics. What do I mean by that? Anyone who has done research on widely recommended software books knows that the list of classics is long and intimidating. Code Complete is the only book I've seen that incorporates ideas from dozens of classic works. There is an entire chapter based around Martin Fowler's Refactoring. The Mythical Man Month and The Pragmatic Programmer are quoted throughout. McConnell ends the book with a software developer reading plan that includes him giving a great testimonial for Programming Pearls. There are also references to Effective C++, Peopleware, and Kent Beck's TDD just to name a few more.Finally, to show I'm not a total fanboy, I'll list a few things that were a little disappointing.1.) McConnell dismisses functional programming pretty early on in the book. He believes in avoiding recursion unless its going to save you a massive amount of coding. While I wasn't expecting functional programming to be a core value in the book, I think it looks bad 11 years later that it was waved off as inconsequential. And for those who are wondering, no, SICP did not get a shout out.2.) Going back to the Microsoft connection, I feel as if the words "open source" were tiptoed around. To his credit, McConnell does recommend SourceForge as a place to look at production code that is likely well-written. However, the way it was presented felt as if he was walking through a landmine and trying not to set a suit on fire.3.) Similarly, the value of Unix tools felt downplayed. The tooling chapter felt it was more appropriate to describe tools anonymously because tools change over time. While there is definitely some truth to that, it felt a bit like a way to justify confining Unix tools to a paragraph.In summary, I would recommend this book to programmers at any level. Its one heck of an education for around $30 and deserves its reputation as a classic. When you finish, you will feel as if you completed a long apprenticeship with a master.