Writing Solid Code

by Steve Maguire (Microsoft Press, 1993, ISBN 1-55615-551-4)
reviewed by Brian Marick on September 16, 1996.
Buy this book from fatbrain.com technical bookstore

From the introduction:
"With the growing complexity of software and the associated climb in bug rates, it's becoming increasingly necessary for programmers to produce bug-free code much earlier in the development cycle, before the code is first sent to Testing. The key to writing bug-free code is to become more aware of how bugs come about. Programmers can cultivate this awareness by asking themselves two simple questions about every bug they encounter: "How could I have prevented this bug?" and "How could I have automatically detected this bug?" The guidelines in this book are the results of regularly asking these two questions over a number of years."

There are exciting programmers and dull programmers. (We're talking in relative terms, here.) The exciting programmers are the ones fixing the showstopper bugs. When they have time to come to the all-project meeting, all eyes are on them. Will they be the hero once again? Will they rescue the maiden of the product, currently tied to the rails as the train named "Ship Date" bears down on her?

The dull programmers always come to the project meeting, but no one ever pays any attention to them because their code is not in crisis.

This book is for those who aspire to dullness. It covers these topics:

1. using compilers, static analysis tools, and automated unit tests to find bugs quickly.
2. using assertions to cause "impossible" situations to be detected quickly.
3. adding more elaborate integrity checking to subsystems in order to catch more bugs.
4. the virtues of stepping through every line of code using the debugger.
5. designing interfaces that are less likely to be misused.
6. miscellaneous tricks of the C programmer's trade.
7. the importance of good habits and attitude.

Writing Solid Code is especially useful for novice programmers who don't realize that they're allowed to do anything other than write feature code. This book will tell them what to do to minimize the risk that they'll become the unwelcome focus of attention later in the project. (In this it differs from other books that emphasize techniques that cost in the short term but pay back in later releases.)

Programmers who are already dull may not find much new here, but Maguire often puts new twists on familiar ideas. And the book's brief case histories do provide useful ammunition. The next time management gets audibly nervous about how much time is being spent on consistency checking code, you can say, "Look here on page 36. Parts of Microsoft Excel do similar checking, and Maguire claims on page 70 that Excel almost never has bugs in the code with thorough subsystem checks."

Programmers who are addicted to excitement will not like this book.

Quibbles:

1. Maguire wisely advocates stepping through each routine in the debugger before deciding it works. Though he doesn't come right out and say it - probably wisely, in a book for programmers - he's talking about test design. His test design criteria are based on the structure of the routine: you pick inputs that will exercise each statement and each path through a branching statement. That's good for certain types of bugs (misimplemented statements and logical tests), but it can be improved by thinking about the data being processed. As it is, the reader wanting to know about data-driven test design has to go to testing books, none of which are written in a way that's friendly to programmers.
2. Everywhere in the world, testers are crying out for test support code to be added to the product. And often getting the reaction I once got: "I don't want to crud up the kernel with that." (As if that version of the UNIX kernel was a pristine and perfect jewel, not to be sullied, when in fact it was commonly referred to as the "Winchester Mystery Kernel".) The code they need is so close to the debugging code Maguire talks about, often only a trivial variation, that I'm saddened he didn't point out to programmers how easily they can help testers.
3. The book should be updated to cover C++, though there are other books that cover error-prone C++ constructs.

Bottom line: This book is wonderful airplane reading for programmers. It's a fast read with solid ideas. Until Microsoft Press botched a bulk order so spectacularly that they lost my business, I handed this book out to everyone who took my course on developer testing. If I were a development lead, I would give it to all my developers.

This book will help you with the following tasks

Click on the task name to see other works that address the same task.

Architectural design and detailed design

The discussion of how to design interfaces that are less likely to be misused will be especially useful.

Debugging

Maguire says code that fails should do so quickly and obviously. Code that does so is easier to debug.

Developer testing

The discussion of test design is weak; the discussion of test implementation is strong (though much of the discussion is disguised as a discussion of debugging).

Managing developers

Good managers should know what good developers do.

Notes on using this book

This book is written for developers wanting to improve their own code. Debugging the Development Process, also by Maguire, is written for development leads who want to help others. Both developers and development leads could benefit from reading both books.

This book's table of contents

1. A Hypothetical Compiler
2. Assert Yourself
3. Fortify Your Subsystems
4. Step Through Your Code
5. Candy-Machine Interfaces
6. Risky Business
7. Treacheries of the Trade
8. The Rest is Attitude
Epilogue: Where Do You Go From Here?
Appendix A: Coding Checklists
Appendix B: Memory Logging Routines
Appendix C: Answers