Re: Defensive Programming

In my experience, my own particular brand of defensive programming is to defend me from myself. I can almost guarantee that most of my mistakes come at 2:00AM, after an evening of caffiene jolts and with music blaring into my headphones.

My own list of defenses are probably very similar to most of the other monks (I have seen quite a few) so I won't go into much detail. Heres one example of the things I do:

# Number 1: the trailing return
sub blah
{
 if($somevar == $somevalue)
 {
    return $this;
 }
 else
 {
   return $that;
 }
 return;
}
[download]

I had an argument with my boss for a while about doing this. But it does nothing, harms nooone so why not (well that was my argument :P).

I think it is easy to confuse defensive programming with secure programming but I see them as two separate disciplines.

Defensive programming should, in my opinion, be about how you program. Thus it allows you to affect the design of the program as well as how you implement it. After all, if an algorithm or code snippet (more likely) goes against your own brand of superstition then who would honestly not re-write it? I know that the first thing I would do with code from another person is go through it with a fine toothcomb.

Comment on Re: Defensive Programming Download Code

Replies are listed 'Best First'.
Re (tilly) 2: Defensive Programming by tilly (Archbishop) on Jan 15, 2002 at 03:50 UTC
You know that that return shouldn't happen, right? So if someone changes your function so that it can avoid any of the meaningful returns, something is probably wrong, right? Wouldn't you like to know about it in that situation? For that reason I sometimes do something like the above, except instead of a return I use Carp's confess and confess that I don't know how I got there. This is particularly useful I find after "endless loops" that I return out of. Should I fall out of the loop (something which I intend to be impossible), that is a programming logic error and I darned well want to catch the mistake sooner rather than later.	[reply]
Re: Re: Defensive Programming by blakem (Monsignor) on Jan 15, 2002 at 00:00 UTC
If that was really the whole construct (i.e. you've already generated $this and $that elsewhere) why not use: `return $somevar == $somevalue ? $this : $that;` [download] Which is a lot easier for me to read w/o all that syntatic clutter around.... -Blake	[reply] [d/l]
Re: Re: Defensive Programming by gav^ (Curate) on Jan 14, 2002 at 23:55 UTC
Personally I think it's bad style. You now have dead code that will never execute. It's also confusing as it made me think for second and go, "hang on, the else will catch everything else". Dead code is a bad thing. Let's not start introducing it deliberatly... gav^	[reply]
Re(2): Defensive Programming by FoxtrotUniform (Prior) on Jan 15, 2002 at 02:02 UTC
But it does nothing, harms nooone so why not "Hmm, have to make `blah` call `foo` somewhere. I'll just throw it in at the end, before the `return`." "WTF?! Why isn't `foo` getting called?" "F&@%$&@!!" The extra `return` is misleading. On the other hand, this example does* demonstrate another good defensive programming practice: always always ALWAYS put a default `else` on your conditionals, even (especially) if that condition "can't happen". `-- :wq`	[reply]
Re: Re: Defensive Programming by seattlejohn (Deacon) on Jan 15, 2002 at 12:13 UTC
While I'm a believer in defensive programming in many ways, I can't help but wonder if in this particular case, the cure is worse than the disease. The subroutine's caller is presumably expecting a valid response ($this or $that, say), yet the code has a fallback case where the routine simply returns something... who knows what. This strikes me as a potential debugging nightmare, because if something gets fouled up in the sub, the program might not break right away -- the sub would just return some (probably bogus) data, which could keep getting processed until it causes some bug way later in the program. Such bugs are, in my experience, extraordinarily hard to track down, because it's hard to know where they even originated. If I were worried about the possibility that I might forget to explicitly return a value from within one of the branches of my if statement, I'd probably code the sub more like this: `sub blah { if($somevar == $somevalue) { return $this; } else { return $that; } die "Something very bad is happening"; }` [download] which is to say, I would try to scream about the problem as early in the logic chain as possible, rather than sweep it under the rug where someone else might trip over it later.	[reply] [d/l]