Rating: 
Summary: Don't buy this book if you ENJOY debugging code!
Review: Having read a number of reviews of this book several weeks ago
I decided to give it a go! After reading just 2 chapters I was
implementing a number of his suggestions. Although the title of
the book concerns development using C, I have found it very
helpful in writing in Delphi. If you think that code should read like a mystery novel, where
every new line leads to yet another mystery. Where you must
continually refer back to previous chapters to follow the flow
of what is happening.....don't buy this book! The author makes
the very valid point that reading code should be like reading the
most boring novel you have ever seen. Every line of code should
be obvious in it's function. When the code does something with
a value, you should say to yourself "I knew you were going to do
that!" If you like to do everything in the most "tricky" way you
can, hide the purpose for each loop and enjoy "side effects"...
either read this book and evolve to be something better than you
are now or stay away from me and my code! Maguire makes a number of suggestions for making your software
verify as much of it's data structures, function calls etc. as
it can during startup. He quotes a number of cases from his
experiences in Microsoft and pulls no punches about how some
things used to be done, but at the same time was truly amazed at
how sophisticated some of the internal error checking and system
monitoring functionality worked. I have noted that most of the reviews of the book which 'can it'
seem to be from people who have either never even seen the book
or who have some bone to pick with Microsoft - some of it with
perhaps good reason, and some without! The concepts presented
in the book may not be earthbreaking, but they have enabled me to
modify my current software development to produce code which will
tell me if I have missed coding something! It will tell me if
I have spelt a string value incorrectly! It has even enabled me
to rewrite whole classes where they are extensible without
writing a single line of code!!! And if you don't have to write
new code, you can't get new bugs! Try it, I think you will like it!
Rating: 
Summary: Please ignore previous negative reviews
Review: 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.
Rating:
Summary: Please ignore previous negative reviews
Review: 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.
Rating:
Summary: Very good book on preventing C and C++ bugs
Review: I'm posting this mostly to counteract the buffoons who obviously gave this book a poor rating only because it was published by Microsoft Press. That's like criticizing Core Java 2 because you don't like Sun. MS Press actually has an enviable stable of writers, and publishes many fine books. Ever heard of Steve McConnell? Jeff Prosise? Charles Petzold? Anyway, this book is a very good source of advice on preventing C bugs on any platform. At one company where I worked, the VP of Engineering used to loan it to many programmers fresh out of college. Like Practice of Programming, it helps you get from what you learn in school to what will help you write production code in the real world. I don't give it 5 stars because it's just not really a classic. You should give it a read if you program C or C++, though.
Rating: 
Summary: Avoid this book
Review: I've never written a review here before, but I feel I should warn people against this book. I bought it myself, because of the positive reviews here. This book will NOT teach you to write solid code, at least not the way I see it. For one thing, it's dated, the examples are written in C, not C++ or some other object-oriented language. That wouldn't matter if it was good advice as sound design can be language-independent. However, in my opinion, it isn't. To start with naming, he uses Hungarian notation (which is a way of putting the type of the variable in the variable name (which doesn't give much meaning in C++, with user-defined types)), like "pchFrom", which means "pointer to char," which gives cryptic variable names, reminiscent of much C code. If you get past that, he offers among other things, the following suggestions. The first ones are about the compiler. He suggests that the compiler should be able to catch the following "mistake": while(size-- > 0); // ";" should not be here, in this case. *pchTo++=*pchFrom++; I don't want an infantilizing compiler telling me I shouldn't have an empty statement following a "while," thank you very much. Other advice is (with my comments after the quotes): "Maintain both ship and debug versions of your program." - Don't. Don't duplicate code. He actually means having separate code for both versions. That means having to maintain both, and even if you fixed it in the debug version, it's not in the ship version. He advocates using comments to explain unclear things. I prefer to have code self-documenting. That way, it's always up to date, too. If the code is unclear, rewrite it. But the really bad advice, the one that compelled me to write this, is in the last chapter (before the Epilogue), in the section entitled "Are you a code meddeler?", and the advice is "Don't clean up code unless the cleanup is critical to the product's success." My advice is "Don't even think about it." If you don't clean up messy code, you almost guaranteed have a bug waiting to happen there. Nuff said. Not to mention the problem of maintaining such code. His intent is, don't mess with code you don't understand. But again, if it's not understandable, make it understandable. This _would_ explain some of Microsoft's products. There are some good advice there, but it's buried in the bad ones, making it dangerous. I would return this book, if I could. I have many programming books. If you want to write good code, I rcommend "Extreme Programming Explained" by Beck, "Refactoring" by Fowler, and "Design Patterns" by Gamma et. al. Highly recommended. "Effective C++" and "More Effective C++" are also good.
Rating:
Summary: Just because its printed by the Microsoft press...
Review: Mr. Maguire is an experienced programmer, and this shows in his book. You'll find a lot of his advice useful. Sometimes though, one gets the impression that the author's showing off all that he's learnt. The book offers advice on how to write bug-free code (or as close to bug free as possible :). It is NOT for beginner, but if you've been programming for even a few months, you'll learn from it. Its not a 'dry' read either. While nothing should be taken as the final word in how to do things/code, condiser Mr. Maguir a teacher imparting his experience through the book. Finally, I disagree with the reviewers who feel that anything printed by the Microsoft press/written by Microsoft's engineers is no good.
Rating:
Summary: Good tips and habits
Review: Programming is a mental practice. This is a good book for preparing the programmer phsychologically for succees. Success of a programmer has an inverse relation to the amount of bugs produced by him/her. This book tries to minimize programming bugs by building positive habits in the practice.
Rating:
Summary: Still Offers Good Advice
Review: 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.
Rating:
Summary: Overall excellent book, with a few flaws
Review: 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.
Rating:
Summary: Is this book a joke?
Review: This book is about writing bug free programs in C. A truly daunting task. All the examples and specifics are in C. You remember this language after Pascal and before C++, Java, C#? Though the contents is valuable for programming in any language the book would be quite hard to read without some C knowledge. On the other side it is good enough to have a quite faded ten-year-old remembrance of the language. The examples are crystal clear and well explained. This is an absolutely worthwhile book and not only for the nostalgic feelings of times gone by.
| 
