Customer Reviews

Writing Solid Code (Microsoft Programming Series)

5 star:		(16)
4 star:		(17)
3 star:		(2)
2 star:		(5)
1 star:		(5)

 

 

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.

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.

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.

Writing Solid Code was first published over eight years ago and concerns a subject, development in C, that hasn't gotten much press lately. In an era where it seems like everything is OO and developed in C++ or Java, the simple truth is C and non-OO development still has a strong place in our industry. This may explain why a book such as this continues to draw attention.

The writing has a feel of the old C classics such as The Elements of Programming Style (Kernighan, Plauger) which also offered lots of advice with little or no formal reasoning or literature citations to back up that advice. As a consequence, the text has a personal, easy flow but contains some recommendations which are questionable at best.

First, I should outline what is right with this work. There are many nuggets of wisdom that seem obvious if not uncontroversial: enable all compiler warnings, use lint, use assertions, and don't wait until you have a bug to step through your code. Enough of these reasonable guidelines appear in the text to lull the reader into a false sense of security with the remainder of the work.

What makes this book dangerous for new developers is the number of points that are either marginal in value or just plain wrong. While it is impossible to give a comprehensive list in a brief review, here is a few: arguments against defensive programming, don't ship the debug version, avoid boolean arguments, and don't clean up code unless the clean-up is critical to the product's success.

Finally, the recommendation "Make it fast, even if it is not guaranteed to be portable" flys in the face of one of the biggest success stories mentioned early in the book: getting Microsoft to build the Macintosh version directly from the newly created Windows source and sharing 80% of the code (with the accompanying savings) in the process. The truth is, a typical piece of software's life is significantly longer than the hardware it was written for and, therefore, will be ported.

It is possible to write C code so it is reasonably portable, readable, and "modern in every way." In the book's defense, this wasn't strictly the purpose and scope of the book. Instead, the book was "Microsoft's techniques for developing bug-free C programs." In the early 1990's, Microsoft had to deliver software on slow processors with a segmented memory model. I got the sense that some of the recommendations in this book were due to those constraints (which are no longer present--even on Windows machines at this point).

Until and unless MS Press updates the work to relax some of the recommendations obviously aimed at managing primative hardware and immature software I can't recommend this book. If, however, such a revision was made that included those changes and the additions of such notions as Refactoring (Fowler) this could be a valuable resource for C programmers or those who which to develop C coding standards.

This is one of the best books on programming ever written. Maguire concentrates on how to eradicate bugs early in the cycle. At first what he says seems so simple. But these ideas are so powerful, and so well presented, that I'd give a copy to every programmer I know if I could afford to.

Don't worry that his examples are in C. The ideas transcend the source language. If half of the programmers followed half of his suggestions half of the time, the software industry would undergo a revolution in quality. There is no silver bullet, but these suggestions are so practical. It's just a matter of adopting a few good habbits.

This book will be a classic. Scratch that. It *is* a classic.

If you're a programmer, it belongs on your shelf beside _Programming Pearls_, _Code Complete_, and Knuth.

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.

This book contains practical advice on how to write bug-free code. It covers a large number of guidelines which are generally applicable to all software development projects.

My only caution is that these techniques, when applied by novice programmers, is no doubt the source of much of Microsoft's code bloat. Also, encouraging the programmer to rely heavily on the source-level debugger can prevent developers from getting a real sense of the program's performance on user-level hardware.

Otherwise, a very good book and very useful advice, much of which I've been applying in my own projects.

This book is a must have for anyone writing code in C or C++. It explains how to properly use debug code such as asserts and other techniques to write more reliable code. I learned several techniques that I now use every day without ever thinking about it. I shudder when I look at old code I wrote before reading this book. Writing Solid Code is literally required reading in many software engineering departments. Steve also relates several stories about bugs in Excel or other Microsoft products that were caught using these techniques or that would have been caught if the techniques were used. Any C/C++ programmer, no matter how much or how little experience, could benefit from reading this book.

The presentation of the content - as noted by other reviews - may not be 5 star, but the content definitely makes up for any failings of the book. The book consolidates practices and information that every programmer should know. Its one of the few books I'd recommend to any programmer.

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!