|P is for Practical|
Re^7: Regex Or Die! (more)by tye (Cardinal)
|on Oct 04, 2006 at 00:45 UTC||Need Help??|
The most recent example went something like:
followed by "Why does this die!??"
The "if" is a structural element and so it is easy to tune out some details of it when concentrating on the code. In this case, the author tuned out that it wasn't an "unless" like they had originally considered writing.
It reminds me of the doors with identical handles on both sides and "push" and "pull" labels when they should either have handles that facilitate just pushing / pulling on the appropriate side or just open both ways (and should never have labels). When you go through a door, your goal is what is on the other side and you tune out the mechanics of the door, and a label doesn't help much here (even though "push" and "pull" labels seem obvious and clear). A label on the door that says "Dept. of Waste Management" works great, however.
Or, another way to look at it is having a label on a door that says "all services except Dept. of Waste Management here". Perl code is about "what to do next"; it is all about "now" and actions. Trying to use parts of English that are about "not now" and "actions to avoid" doesn't mix as well.
The times I've seen this problem "fire", it was very similar to the example above. It was quite simple code and the programmer (usually also the author of the code) goes over it again and again trying to figure out why the conditional is/isn't firing when it shouldn't/should be... to the point of exasperation.
So examples of actual code really aren't very interesting or useful in understanding the problem, other than to see that the code is trivial or nearly so.
BTW, I don't see the distinction between "if not" and "except if". One negates the conditional and the other negates the action, so I'm not sure why you'd see one negation as easy to "lose" while the other is "impossible" to lose. Oh, I guess negating the conditional fits Perl code while negating the action doesn't, if that was your realization.
For me, I agree with the many who have said that combining complex conditional expressions with "unless" is a bad idea. And I find "if not EXPR" just as easy (and smooth) to read as "unless EXPR" so I see no reason to use "unless" for the case of a simple expression (they mean the same thing, as has been pointed out over and over). That leaves me with no reason to ever use "unless" and several reasons (some subtle) to not use it.
As the years go by, I find more and more that a conservative "taste" in code design is very likely to pay off in the long run. A lack of "KISS" has become "code smell" to me.
and I see neither an end nor any benefit coming from it.
I see some getting upset (to the point of making snide remarks about it in other threads) but the existance of a cranky, noisy minority(?) doesn't mean that there isn't a silent majority(?) that can accept information without feeling attacked. (: Since it hasn't turned into a flame war from my perspective (I feel quite calm and jovial at the moment), I don't mind trying to explain better when asked. Though, if I can't come up with any ways of expressing this that I don't feel I've already done a reasonable job of presenting, then I won't repeat myself endlessly. So I don't see why there shouldn't "be an end" (I certainly don't expect to have "an end" where everyone agrees).
Oh, and I'm not even trying to deprecate "unless". The lack of "use strict" has not been deprecated (as in, at some future point it will become impossible to have strictures disabled). I'm explaining why some may choose to avoid using "unless", at least in certain types of code. "Avoid" doesn't even mean "never"; it more means that you have to have an unusual reason to justify using it (in the described situations).