What This Book Means to Me
I'd seen this book originally on mozillazine.org as a JWZ reccomendation. Having read design docs by him before, I was inclined to trust his praise of the book. And what a read it was! If you're like me, or hurstdog, you'll breeze through the book in no time. Easy to follow examples and end of chapter exercises, combined with MS development anecdotes, make for an engaging read.
Outline of the Book
Table of Contents
1 A Hypothetical Compiler
How to use compiler warnings to avoid embryonic bugs (warnings about using uninitialized variable use). This chapter also examines what the software won't do in terms of bug catching (like = instead of == with the lvalue being a variable).
2 Assert Yourself
Proper useage of assertations and error conditions. If you've never taken an advanced class on programming (most DIY OpenSource people), you're probably misusing assertation calls. This chapter also outlines extra sanity checks you can add to the debug version to spot algorithm issues before they become data shredders.
3 Fortify Your Subsystems
More aggressive than assertations alone, strict checking of your functions' arguments can help stop other programmers from misusing your functions to get results. The example code in this chapter includes a memory allocation subsystem.
4 Step Through Your Code
By quickly examining the data flow through any new code or algorihtms, you can spot bugs as you introduce them. It also mentions how stepping through code doesn't take very long, especially compared to hours finding hard to reproduce bugs.
5 Candy-Machine Interfaces
How to remove the bugs (rather than treat the symptoms of them) by having a properly designed API. The real-world results are best illustrated by the OpenBSD project's API of strlcpy and strlcat, which are consistent and easy to use (hard to misuse).
6 Risky Business
Where and when to trade risky, crash prone algorithms for safer, more reliable ones. How best to avoid language idioms in the quest for more performance.
7 Treacheries of the Trade
A deeper look at dangerous habits programmers have, and how to address them.
8 The Rest is Attitude
The most important chapter of the book -- the one addressing the atitude at programmers. Things to think about, goal wise, while writing code which will reduce your bug count.
Why This Book Is Important
When I go to write something for Gnome, and I'm forced to grep through megabytes of source to get examples of how to use an API, I know that the people who wrote that API could use this book. The lack of proper programmer documentation, subsystem checks, and easy to misuse APIs of many big name projects (such as the Linux Kernel, Gnome, and others), would be fewer in number if this book was more widely read. It would reduce the release of code which is not fit for others to work on.
I once spent a week tracking down obscure memory leaks in a program I wrote which displays RSS news in the Gnome panel. I used memprof, a great debugging tool which let me track where memory was being allocated and not freed from. Every single one of the 3 leaks I found was because I had misused an API. Other bugs I've had to deal with were because of a lack of documentation (gdxpixbuf dereferencing is not explained well, for example). When the docs fail me, I go read code wich has the API used in it. But these examples are also often flawed. Then there are programs which have large problems (like the Gnome Tasklist applet, which leaks ~250kb memory each time I switch virtual desktops) that should have been dealt with long ago.
After reading this book, and thinking about the discussions on the Linux Kernel mailing list, I understood why a lot of professional programmers sneer at the kernel. I'm surprised it works as well as it does (or maybe I'm not, considering 2.4.5 is still not ready for production use, despite 4 months of useage/hacking). I see a lot of OpenSource which can benefit from the information this book teaches. Just ignore the bits about Hungarian notation :)
You'll probably just want to borrow this from a friend if you don't program in C, since most of the specific examples and same of the advice does not apply to higher languages (like Perl or Python)
How To Get This Book
I found my copy at the MIT co-op bookstore. It seems pretty hard to find in "traditional" book stores which only stock "For complete computer illiterate retards" ™ books, but it can be had easily online thanks to Fatbrain. Their price for the book is for 19.96$.
Title: Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs
Author: Steve Maguire
Publisher: Microsoft Press
Price: $24.95 USD || $32.95 CDN
Date: May, 1993