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.