"defensive programming" (Was: Re: How nice should I be on exit?)

[Luke Gorrie]

Vance Shipley <vances@REDACTED> writes:

> It takes some getting used to though as we tend to want to program
> defensively.

I'm not sure if this has confused anyone else, but I think there are
two definitions of "defensive programming" floating around. For years
I'd been a bit confused about the standard "don't program defensively"
Erlang advice, but just recently I saw a definition of what that
really means. I was doing some remedial programming study with a copy
of "Software Tools" by Kernighan and Plauger that I borrowed from an
Erlang programmer, and found this text marked in pencil:

  A point of style: After appending a short string to the buffer, we
  tested whether 'nsave' was equal to _or greater than_ its maximum
  safe value. But from reading the code, we _know_ that 'nsave' can
  never exceed MAXCHUNK or go negative, so why bother?

  This is what is known as "defensive programming." It costs next to
  nothing in source text or execution time, yet it reduces the chance
  of the program going wild should an important control variable
  somehow be damaged. You can't print out error messages everywhere,
  but you can and should take out insurance whenever possible.

  It is much easier to debug a program if the output is not voluminous
  and if additional storage overwrites do not occur as a side effect
  of the original bug. The way to ensure saner behaviour is to do the
  sort of things we did. Write your 'if', 'while', and 'until' tests
  so they steer crazy situations back in a safe direction. Use the
  last 'else' of a chain of 'else-if's to catch conditions that should
  "never" occur, but just might. Never check for equality if it
  doesn't hurt to check for "greater than or equal to" or for "less
  than or equal to."  In particular, don't let loops repeat when a
  variable is out of its expected range. Don't make your program a
  sucker for bugs.

So, they're talking about trying to continue somehow after reaching
"impossible" states, and I can see that this is against the Erlang
philosophy. Taking this definition, the "don't program defensively in
Erlang" advice makes perfect sense.

The other definition of defensive programming comes, I think, from
"Code Complete" by Steve McConnel. In this one, being "defensive"
means not blindly trusting your inputs, and instead checking them with
assertions so that you detect "impossible" states and fail as soon as
possible. This is very much in line with the Erlang philosophy - it's
like putting strict guards on your functions so that calling them with
bad arguments will cause a crash. Using this definition, "don't
program defensively" would mean "don't bother with extra guards and
stricter pattern matches", which would be totally against the grain of
all the other rules, and does indeed cause confusion :-)

Hope that clears things up for someone else who learned the other
definition than the Erlang guys :-)

Cheers,
Luke