Latest LQ Deal: Linux Power User Bundle
Go Back > Reviews > Books > Programming
User Name


Search · Register · Submit New Review · Download your favorite Linux Distributions ·

Writing Solid Code
Reviews Views Date of last review
1 19813 07-02-2004
Recommended By Average Price Average Rating
100% of reviewers $24.95 10.0

Description: "Microsoft's Techniques for Developing Bug-Free C Programs" (publisher).
IMHO, applicable to most areas of program development providing a practical guide on how to write bug free code from day one and how to keep it bug free. i.e. how Microsoft should have done it, given sufficient incentive.
Keywords: programming c code bug security coding practice
Publisher: Microsoft Press
ISBN: 1-55615-551-4

Post A Reply 
Old 07-02-2004, 03:54 PM   #1
Registered: Nov 2001
Distribution: Fedora
Posts: 161

Rep: Reputation:
Would you recommend the product? yes | Price you paid?: $24.95 | Rating: 10

Pros: Very readable, checklists and ideas at every stage.
Cons: Er, Microsoft?

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.)


All times are GMT -5. The time now is 08:35 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration