Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs
. Microsoft Press
Develop bug-free code with guidance from former Microsoft developer, SteveMaguire
, this book presents practical approaches to detecting and preventing bugs early in the development cycle.
Writing Solid Code (20th Anniversary 2nd Edition)
Microsoft's Techniques for Developing Bug-Free C Programs
A short book then? No - there's a different technique for each bug
Don't let the subtitle put you off. There's a great deal of good advice given here, mostly practical, some less so. It makes you wonder how many of the techniques are actually practiced at MicroSoft
. It probably should also be added that most techniques for writing good code require good programmers.
Not to be confused with SteveMcConnell
, author of CodeComplete
and another former Microsoft developer.
A few examples of the advice are:
- Enable all the diagnostics of your development tools -- I totally agree with this one. When I do C, I always use -Wall -ansi -pedantic, and I make sure to actually *fix* the stuff it warns me about.
- Use debugging aids like assert()
- Write error detection into wrappers for your subsystems
- Step through your code in a symbolic debugger, watching the data flow
- Design functions that are hard to misuse
- Design subsystems for testability
- Know the common pitfalls of your language and resist the urge to write "clever" code
- Have the right attitude: don't think of a bug as something that "just happens".
Some of the advice in this book is dated (for example, his admonishment against "cleaning up code" was written before disciplined refactoring became well known), and much is C-specific. Some of the ideas can be applied to more modern environments, but it would be nice to see a more updated version.
All new hires at MicroSoft
are given both WritingSolidCode
so that they get deep into MicroSoft
coding culture fast.
What I do not understand about MicroSoft
is how they totally obviate UnitTest
s. They prefer to have a human tester verify everything you write. That's the opposite of RapidFeedback
, no matter how fast the tester is.
A lengthy and unfavorable criticism of this book: