Writing Solid Code (Microsoft Programming Series) [Paperback]

Steve Maguire (Author)

Book Description

Publication Date: January 1, 1993

For professional intermediates to advanced C programmers who develop software, here is a focused and practical book based on writing bug-free programs in C. Includes practical solutions to detect mistakes before they become a costly problem.

Editorial Reviews

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.

Product Details

• Paperback: 256 pages
• Publisher: Microsoft Press; 1 edition (January 1, 1993)
• Language: English
• ISBN-10: 1556155514
• ISBN-13: 978-1556155512
• Product Dimensions: 9.1 x 7.3 x 0.9 inches
• Shipping Weight: 1.4 pounds
• Average Customer Review: 3.8 out of 5 stars  See all reviews (45 customer reviews)
• Amazon Best Sellers Rank: #322,954 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

40 of 41 people found the following review helpful:

4.0 out of 5 stars Still Offers Good Advice, December 4, 2002

By 

Paul J. Mantyla (Sunnyvale, CA USA) - See all my reviews
(REAL NAME)   

This review is from: Writing Solid Code (Microsoft Programming Series) (Paperback)

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.

21 of 21 people found the following review helpful:

5.0 out of 5 stars Please ignore previous negative reviews, November 22, 2003

By 

Robert O. Alexander (Bellevue, WA United States) - See all my reviews
(REAL NAME)   

This review is from: Writing Solid Code (Microsoft Programming Series) (Paperback)

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.

15 of 15 people found the following review helpful:

4.0 out of 5 stars Overall excellent book, with a few flaws, April 27, 2001

By 

Somebody You Don't Know (Portland, OR, USA) - See all my reviews

This review is from: Writing Solid Code (Microsoft Programming Series) (Paperback)

This book in many ways changed the way I approached programming. In particular, the perspective that it took towards designing and implementing programs in a way such that bugs are automatically detected (preferably by the compiler, or by other tools) has proved invaluable to me in my later experience as a software engineer. Other advice (use some form of 'assert' heavily, deliberately write 'brittle' code that will break loudly as soon as the slightest thing goes wrong, so errors aren't hidden) was similarly insightful, if occasionally a bit counterintuitive.

On the other hand, the book's source language (the C programming language, as used by Microsoft tools) is increasingly outdated. This might prevent some people from appreciating the finer insights of this book. Also, the author recommends use of Hungarian notation, which I despise in a strongly typed language. (My recommendation: use PC-Lint, with strong types. Both more powerful, and more readable.) Still, the overall philosophy of the book is very powerful, and the concepts and techniques that it discusses can easily be applied to other programming languages and other software development efforts. I was writing in C++ when I read the book, and I currently program in Java, but I still apply the lessons I learned from this book.

This book is certainly not the ONLY way to write solid code (and I have found improvements on a number of techniques discussed in the book), but it does sketch out a fairly workable process which if followed would produce a quality product. Most importantly, the PHILOSOPHY that the author uses to approach writing bug-resistant programs is quite powerful.

Note that this is a book on software implementation, not software design (except in the small scale). Large-scale design is a whole separate issue which this book really does not address much.