Author: Steve McConnell · Published: 1993 · Genre: Programming, Software Engineering
Code Complete‘s biggest strength is thoroughness: it is the most complete, research-backed guide to the everyday work of designing, writing, testing and debugging code. Its biggest weakness is its sheer bulk, more than 900 pages in the second edition, along with examples and data that now feel old. Working programmers who want one reference on software construction should own it, but should dip in by chapter rather than read it cover to cover.
The core ideas
McConnell focuses on construction: detailed design, coding, debugging, unit testing and integration, rather than requirements or project management.
- Managing complexity is software’s primary technical imperative. Good design and coding practices exist so that no one has to hold much of the program in their head at once.
- Prerequisites matter. A defect introduced early and found late costs far more to fix than one caught quickly, so settle requirements and architecture enough before you write code.
- High-quality routines. Create a routine to reduce complexity, hide information or avoid duplication. Aim for functional cohesion, where a routine does one thing. Give it a name that describes everything it does, and limit parameters to about seven.
- Defensive programming. Use assertions for conditions that should never happen and error handling for conditions that might. Build “barricades” that validate data at the boundary so inner code can trust what it receives.
- The Pseudocode Programming Process. Write a routine as plain-English pseudocode first, refine it, then fill in the code beneath each line, keeping the pseudocode as comments.
What’s great
- Evidence over opinion. McConnell cites hundreds of studies and uses them to back specific advice, for example on how effective code inspections and pair programming are at catching defects compared with testing alone.
- Checklists. Most chapters end with a checklist, on routines, variables, loops or debugging, that works as a ready-made code-review guide.
- Program into your language, not in it. Decide what you want to express, then use the language’s features to express it, rather than limiting your thinking to what the language makes easy. It’s one of the book’s most useful ideas.
- Practical detail. The debugging chapter treats bugs with the scientific method: stabilize the error, form a hypothesis, test it. The code-tuning chapters insist you measure before optimizing, because a small fraction of the code usually accounts for most of the run time. Advice on variables, such as keeping their scope and lifetime as short as possible, is simple and effective.
What’s weak
Size is the obvious problem. Many sections belabor points an experienced developer already knows, and the book repeats itself across chapters.
The second edition appeared in 2004 and has not been updated since. Examples are in C++, Java and Visual Basic, and there is nothing on modern version control workflows, continuous delivery, cloud services or newer languages.
Some of the research is also old, with many studies from the 1970s and 1980s. The writer Laurent Bossavit, in The Leprechauns of Software Engineering, questioned how well that early research supports famous claims such as tenfold productivity differences between programmers and the steeply rising cost of late-found defects, both of which appear here. McConnell has defended his reading of the studies, but readers should treat precise numbers with some caution.
Who should read it
Programmers with a year or two of experience, who have written enough code to recognize the problems it solves. Get the second edition (2004), which supersedes the original entirely. Keep it on the desk and read the chapter that matches the work in front of you.
Rating: 4/5
Image credits — Featured image: cover image via Open Library; cover design © the publisher, shown for review purposes. In-article images: Photo by Kevin Ku on Unsplash.
