OP is checking for defined-ness solely to avoid generation of the warning

I would guess that the warning made the OP stop and think what branch to take in the undef case, and that the OP's code has a good chance of reflecting what was actually wanted.

Quoting OP yet again (emphasis is mine) ...

Always having to check if the variable is defined before testing its value. It just seems soooo unnecessarily verbose.

I, personally, do get your point, and (would) have added the defined test myself.

The urge to silence the uninitialized variable warnings becomes rather strong (in most limited scope, of course), however, when more than a couple of defined tests exists in close proximity just to avoid the damned warnings. Yes, that does prompt me to check why the things are not defined, which sometimes results in anything fruitful.

But really, equality comparison of an undefined variable to anything else should just merrily produce the darned truth value without fuss.

But really, equality comparison of an undefined variable to anything else should just merrily produce the darned truth value without fuss.

Eww. That would be almost as bad as eq returning true, false, or undef (the latter if either operand is undef) ala SQL's NULL handling. I think the existing undef-becomes-""-or-0 is just fine.