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:
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.
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.
Click on the task name to see other works that address the same task.
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.
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