Would you recommend the product? yes | Price you paid?: $24.95 | Rating: 10
Very readable, checklists and ideas at every stage.
Remember how Microsoft got their bad name - bugs and late delivery, right? This book describes the views of one Microsoft author that saved their a$$es on a few occasions.
Asside from having "Microsoft" on it, the book is very good, very readable and contains illustrative examples to back up the commentry. It was the first book I read where they actually discussed "Software Quality".
It uses C as the example language but the concepts are easily portable. It also champions Hungarian notation that can cause arguments on the scale of the Discworld Mage Wars! That aspect you can take or leave.
The central theme is this:
Programs are written by people. They are maintained by people. People have to read the code, decipher the meaning and fix the bugs. Computers, on the other hand, don't read programs - Compilers do (and they are VERY good at it). So: Write your code for human readers!
The second "law":
If you think your obscure one-liner, using every trick in C, is faster than what the optimiser can do, dream on. Don't expect anyone (including yourself in a month's time) to be able to understand it or be able to fix it.
Use every compiler warning available and use the strictest type-checking you can. Imagine if your (paranoid) compiler could identify ALL of your bugs (off by one etc.) - help the compiler, don't hinder it.
The third "law":
Make a "debug" version using the pre-processor. No "debug" code should exist in a "release" binary. The debugging code will probably have bugs in it. You only put it in to see what was going wrong in the first place. Once the problem is fixed are you going to single-step through the debugging code?
As mentioned, I found this book very easy to read and the main points stood out as they should. If you have ever written code for MS MFC then you'll be right at home. As for Linux kernel hackers, why not take a peek over the wall? Ignore the bits about variable naming and everything else is just as relevent (`make debug` etc.).
An unreserved recommendation. Buy/borrow/steal a copy, read it and post your own review here. (I have no connection with the Author! I just like the book.)