Product Description

"This book has useful things to say and an engaging way of saying them...a worthwhile addition to the shelves of any full-time programmer." - PC Week. Here, from a former Microsoft developer, are super secrets for developing bug-free C programs. Maguire provides examples of how bugs are caught at Microsoft (using actual case histories) and shows how readers can use these proven programming techniques to get products to market faster.

Product Details

• Amazon Sales Rank: #698237 in Books
• Published on: 1993-01-01
• Original language: English
• Number of items: 1
• Binding: Paperback
• 256 pages

Amazon.com Review
Any programmer worth their silicon knows that it is wiser to invest time preventing bugs from hatching than to try to exterminate them afterwards. And this is one of the best books for developing a proactive attitude towards electronic entomology. Follow Maguire's advice, and your testers, supervisors and customers will love you. Recommended.

Customer Reviews

Still Offers Good Advice
The negative reviews I've read tend to fall into two categories: 1) Anti-Microsoft Bashing and 2) Nitpicking.

This book isn't a recipe book, and it's a bit dated, having been written during the days of DOS and the first Macintosh, but the underlying themes and general advice are still valid:

- Enable compiler warnings and pay attention to them.
- Use assertions to validate your assumptions.
- Don't quietly ignore error conditions or invalid input.
- For a complicated, critical algorithm, consider using a second algorithm to validate the first. (e.g. validate binary search with a linear search).
- Don't write multi-purpose functions such as realloc (it can grow memory, shrink memory, free memory, or allocate new memory -- it does it all).
- Check boundary conditions carefully.
- Avoid risky language idioms.
- Write code for the "average" programmer. Don't make the "average" programmer reach for a reference manual to understand your code.
- Fix bugs now, not later.
- There are no free features; don't allow needless flexibility (like realloc).
- Ultimately the developer is responsible for finding bugs; he shouldn't write sloppy code and hope that QA will find all his bugs.

Please ignore previous negative reviews
I was shocked to see this book get some negative reviews. Those that blasted Microsoft missed the point. This book provides invaluable advice in a quick read. For example, "If you have to look it up, the code is not obvious," or, "If you find yourself designing a function so that it returns an error, stop and ask yourself whether there's any way you can redfined the function to eliminate the error condition." This is the book that convinced me to single-step all my code. The heuristics on proactive bug prevention, which are summarized in the appendix by the way, will save your team time and let you move on to adding features rather than fighting fires.

Flaws and outdated advice detract from otherwise good advice
Writing Solid Code was first published over eight years ago and concerns a subject, development in C, that hasn't gotten much press lately. In an era where it seems like everything is OO and developed in C++ or Java, the simple truth is C and non-OO development still has a strong place in our industry. This may explain why a book such as this continues to draw attention.

The writing has a feel of the old C classics such as The Elements of Programming Style (Kernighan, Plauger) which also offered lots of advice with little or no formal reasoning or literature citations to back up that advice. As a consequence, the text has a personal, easy flow but contains some recommendations which are questionable at best.

First, I should outline what is right with this work. There are many nuggets of wisdom that seem obvious if not uncontroversial: enable all compiler warnings, use lint, use assertions, and don't wait until you have a bug to step through your code. Enough of these reasonable guidelines appear in the text to lull the reader into a false sense of security with the remainder of the work.

What makes this book dangerous for new developers is the number of points that are either marginal in value or just plain wrong. While it is impossible to give a comprehensive list in a brief review, here is a few: arguments against defensive programming, don't ship the debug version, avoid boolean arguments, and don't clean up code unless the clean-up is critical to the product's success.

Finally, the recommendation "Make it fast, even if it is not guaranteed to be portable" flys in the face of one of the biggest success stories mentioned early in the book: getting Microsoft to build the Macintosh version directly from the newly created Windows source and sharing 80% of the code (with the accompanying savings) in the process. The truth is, a typical piece of software's life is significantly longer than the hardware it was written for and, therefore, will be ported.

It is possible to write C code so it is reasonably portable, readable, and "modern in every way." In the book's defense, this wasn't strictly the purpose and scope of the book. Instead, the book was "Microsoft's techniques for developing bug-free C programs." In the early 1990's, Microsoft had to deliver software on slow processors with a segmented memory model. I got the sense that some of the recommendations in this book were due to those constraints (which are no longer present--even on Windows machines at this point).

Until and unless MS Press updates the work to relax some of the recommendations obviously aimed at managing primative hardware and immature software I can't recommend this book. If, however, such a revision was made that included those changes and the additions of such notions as Refactoring (Fowler) this could be a valuable resource for C programmers or those who which to develop C coding standards.