My house-move is coming up soon, and after a review of my technical books, I decided that some books simply had to be re-read. “Writing Solid Code – Microsoft’s Techniques for Developing Bug-Free C Programs” by Steve Maguire fell into this category. Originally published in 1993, it was a book I had strongly positive memories about.

I was pretty certain that I was doing the right thing to read this again when I read:

Despite what many programmers believe, testers are not there to test your code. That’s your job. If you disagree, name one other job in which it’s acceptable to do slipshod work simply because somebody else is going to review it for mistakes. Why should programming be an exception? If you want to consistently write bug-free code, you must grab the reins and take charge.

I find it hard to express my feelings whenever I have heard that programmers have not had to fix bugs in their own code. When developers have talked about ‘Maintenance Programmers’ fixing bugs they coded, or moving onto another project before it was clear there wasn’t anything else to fix it just seemed very clearly to me a recipe for not learning from your mistakes. Indeed, in general I have had the impression that development shops would move their development teams onto other projects as soon as ship-date hit, leaving some poor sods to maintain the code that simply appeared to fulfil some specified criteria. At the time I originally read this book, I was learning C, through self-interest and with the help of a colleague in another team via email. WSC showed me a whole new way of thinking about coding, and its criticism and proposed fixes to several of the standard memory management routines was an education that things could have been so much better; even of the tiny C language.

Now I am a C# developer, and I have to admit that recalling some C idioms and necessities was sometimes a struggle. Did we really have to manage all our own memory? Did we really not have classes to make coding more manageable?

Perhaps this is just a mind-set thing, and will always be a permanent feature of programming and development. Will there always be some people who will be gung-ho and not seem to care about the aftermath of their efforts, and others will be left to pick up the pieces? Certainly I have colleagues today who still appear to be against unit-tests (despite frameworks that make them so easy to write and run), and who honestly appear to consider that if something works 90% of the time or for one test, then that is fine. It baffles me.

C# and the IDE has certainly removed many (but not all) of the issues that plagued C programmers, and to this end the book has lost some of its relevance to me personally – though I wonder what a C++ programmer would think. How thin would it be if it were rewritten for C#? The truth, of course, is that it would likely fill up with other things that are often misused, abused or misunderstood about C# and .Net.

Overall, I would still recommend the book to someone who has coded in C; if they have not I fear the oddity of some code would so baffle the reader that they would not see some of the basic points: You may not be able to write code so that it is all 100% correct; but you can certainly code so that some of it is 100% correct, and in addition make it far harder for your work to be misused in the future. Careful selection of your coding approach can mean your efforts are rewarded with easier maintenance in when functional changes are necessary, and finally, you can improve on what you do and how you do it by reviewing every bug you find and asking yourself some pertinent questions.