by Chris Douce
by Steve McConnell
Microsoft Press, 2004
Not long after discovering Software Psychology by Ben Shneiderman in the university library, I remember being excited when I stumbled over what almost seemed to be a code oriented contemporary equivalent in a local bookshop: Code Complete.
Leafing through the first edition I remember being particularly struck by the 'hard data' icons and began to recognise a number of the empirically-oriented papers. At the time of finding the first edition I had an emerging interest in some of the more contentious issues in software development, namely identifier naming, commenting and layout. These are some of the issues that Code Complete aims to address, presenting empirical evidence alongside words of practical advice.
The subtitle of Code Complete describes it as a practical handbook to software construction. Divided into a number of parts, the first sets the 'construction' scene. Here McConnell scopes Code Complete. The book is targeted firmly in the arena of the practising programmer whilst giving important nods to the surrounding issues of problem definition, maintenance, approaches for system architecture and testing.
After laying the foundation, design approaches and the programming process is explored. This is then followed by sections exploring the use of data (variables), control flow (statements) and what could be considered as good practice.
Reading a book like Code Complete naturally makes me question my own practices (which is, of course, one of its main intentions). When reading the section on 'developer testing' digesting references to research regarding error rates I couldn't help but think about whether my own practices could be improved.
Programmer performance is an issue that is explored a number of times. In one section, a twenty to one difference in debugging performance between experienced and inexperienced programmers was cited. Another section describes a ten to one difference in the amount of time it takes to construct (or write) a program.
The penultimate chapter, personal character, begins to explain why. Efficient developers and programmers, McConnell argues, do not have to be super intelligent butthey should have an appreciation of how limited one's one mental capacity is. In essence, a programmer needs metacognitive awareness which is an interesting programming education topic. Education and programmer self-education (whether it being reading of books or developing of throw away programs) is a topic which is also explored within Code Complete
The heart of Code Complete is about getting things done the right way, specifically constructing code that does what is intended in a way which doesn't trip other engineers (or artisans) up. This is achieved, it is suggested, by reducing the complexity that a programmer has to deal with from a number of different perspectives. The Code section of Code Complete is all about suggesting efficient ways to formulate information that both human and machine can parse.
A number of complexity management heuristics are: When writing comments, describe 'why' a program does something rather than 'how' it does it since this should be self-evident from the code, and keep them to the point. When using variables don't use crazy names and always try to keep the declaration as close to where it is used. Finally, if in doubt (or think that anyone else may ever be in doubt), parenthesize.
Code Complete combines together two sub-disciplines within the psychology of programming: the psychology of programming using programming languages, and the psychology of software engineering. Here's a quote I like: 'The whole job of programming is building air castles - it's one of the most purely mental activities you can do. Consequently, when software engineers study the essential properties of their tools and raw materials, they find that they're studying people: intellect, character, and other attributes that are less tangible than wood, concrete and steel'.
Those familiar with the first edition of the book will be familiar with the format and contents of this new edition. Much has changed, however, as is evident from the table of contents. There are new sections. Others have moved around or have been combined. This movement is particularly noticible in the first chapters - the introduction into the code aspect of construction is more gradual and is more rounded as a result.
In line with the changes in programming languages, the examples have changed too. Samples written in Pasal, the language of choice for the educator during the eighties to nineties has been replaced by samples in Java. Programs written in C have sensibly migrated into C++.
As languages have changed, more research exploring the human (and engineering) aspects of programming has been carried out. The 'hard data' side bars have been updated with new references and whole sets of new papers described, suggesting reading that will keep some of us going for quite some time.
Since the publication of the first edition the perception of appropriate working practices has also changed. There are now discussions that examine the merits of current engineering approaches such as pair programming. This is presented alongside discussions regarding software quality and the advantages that rigorous code reviews may bring.
I like Code Complete - it is easy to read and very well referenced. It is also code focussed which, for some, will hit the spot. If, however, you want a book regarding the state of the art design practices or information about how to manage a programming team (or even your manager) you can't go far wrong by checking out what Code Complete references. And while you're in the neighbourhood, reading a couple of chapters might do you some good too.
It was also interesting to learn that Robert Pirsig once worked as a software technical writer. Also, if you want to know what Homer Simpson has to do with software engineering I urge you to visit your local library to borrow Code Complete. There's a treat awaiting you.
The companion website to the book can be found at: Code Complete Second Edition
Do you know of a journal that may be of interest to fellow PPIG members? If so, please tell us about it. Interested in writing a review, or perhaps you are an editor and would like to introduce your journal to us? Please feel free to send us a message.