At first, I was surprised at how old it was — 1993! Before Win95 even! Then, it seemed quite out of date. It mostly talks about programming in C on some old, anemic platforms without the niceties that we take for granted, such as hardware faults when dereferencing invalid pointers. So, of course, I’m trying to take higher-level lessons from it, such as the approach he’s taken to develop these bug-eliminating techniques, and then apply that approach to the environment in which I work. Unfortunately, a lot of the techniques have to do with low-level C, where you don’t have a powerful and safe type system or GC to eliminate whole classes of errors. Most of the specific bugs he’s mentioned wouldn’t even arise in Haskell, Python, Java, or C#. Also, this book was written before unit testing and test-driven development were really commonplace, and I think that these supplant some of the techniques Steve mentions. (Not all; there is some overlap between test-driven development and writing bug-free code, but neither TDD nor after-the-fact comprehensive tests give you license to write sloppy code.)

And as I’m thinking about how spoiled we are with our strong typing, garbage collection, and hardware exceptions, I realized that I program every day in an unsafe language that tries as hard as it can to hide errors from you, just like the microcomputers of yore. PHP. I don’t think there’s been a day yet where learning about a PHP design decision hasn’t made me think “WTF”. I mean, why do you need a rich collection of container types such as in STL or java.util? PHP’s array does it all! If you pass too few arguments to a PHP function, that’s okay, the missed ones will just be null. If you pass too many, no problem! They’ll be ignored. Try to append something to an array that _doesn’t even exist_, no problem! It’ll magically create the array! I could go on and on. Anyway, the language actively prevents you from finding bugs.

So, from here on out, I’m going to read the book, trying to apply every technique to PHP. I think there is a lot we can learn. Here’s the first technique that would catch bugs in our code that popped into my head:

function foo($a, $b) {
  tep_assert(count(func_get_args()) == 2);
...

Another one: null, true, and false are considered ‘magic numbers’ without immediately visible context. What does…

updateProgress(true);

…mean? Compare that to…

updateProgress(showNewMessage=true);

It’s well-known that true and false make bad function parameters, but I’d never thought about ‘null’ being a magic number, however. And it is, for the same reasons as true and false above. When you see code like ‘new DialogBox(null)’, what does that null represent?

I’m sure more will come…