Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^3: Burned by precedence rules

by tilly (Archbishop)
on Dec 26, 2008 at 05:00 UTC ( #732634=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Burned by precedence rules
in thread Burned by precedence rules

I disagree strongly with many people then.

When we are debugging we do not reliably do De Morgan's laws in our head. I heard this a long time ago and did not believe it until one particularly frustrating debugging session. Ever since then I've avoided using unless with any kind of logic at all no matter how nicely it reads while I'm coding.


Comment on Re^3: Burned by precedence rules
Re^4: Burned by precedence rules
by gwadej (Chaplain) on Dec 26, 2008 at 13:25 UTC

    While I understand your point and would not dream of trying to convince you to change, I usually try to use unless in very specific contexts. If there is only one condition and it would normally be expressed as a negative, I find unless {cond} much cleaner than if !{cond}.

    I can understand the point about people not being able to DeMorganize in their heads. (I knew a really, really good programmer once who regularly had problems with and and or) But, I have found that sometimes unless is clearer (just like in English.)

    G. Wade
      In that situation I use unless as well. But I flip to if when I need to add and or or.

        Ah! I wasn't clear on that from your statement above.

        This thread does a good job of reminding all of us that it's usually the little things that kill most of our time. I have stopped being surprised how often a nasty bug turns out to be something simple that everyone overlooks because they know beyond a shadow of a doubt what it is doing. Unfortunately, they are wrong.

        G. Wade

      Actually, I've seen the confusion happen with just a simple "unless $bool". Making the negation more explicit tends to help. I've quite recently seen several cases where I and people I've worked with were persistently confused as to how code could be doing what it was doing and it turned out that the part that was confusing us was the use of "unless".

      I've also tried to simply replace an "unless" with an "if" and thus produced a horribly complicated bunch of negations (which I didn't keep). Most of the time, I can find other subtle negations and cancel them out. Things like "unless $count != 0".

      Of course, "unless" seems to be "obviously" the same as "if not". But if the human mind actually worked that way, then there would have been no confusion when I answered "Is this preview button regarding updates not wanted?" with "No". The human mind doesn't do "double negatives" like some claim English does (and thus also not like programming languages do).

      So reduce the number of negations in your programming constructs. And make the negations that you do more explicit. "unless" may be appealing because it eliminates a negation, but it doesn't, it just makes the negation more subtle.

      An example of a really bad subtle double negative is "last unless ...". "last" has a subtle negation in it, since it means "do not keep looping".

      And when a conditional gets complicated, sometimes the best route is to just add one or more named items for different parts of the conditional.

      my $is_logged_in= $user && $user->id() != User->anonymous_id(); my $has_guest_coupon= $cookie && $cookie->is_for_guest() && ! $cookie->is_expired(); if( $is_logged_in || $has_guest_coupon ) {

      or, usually better, especially if the short-circuiting is important:

      if( is_logged_in($user) || has_guest_coupon($cookie) ) {

      - tye        

        In my experience, the difference between if and unless has been less of a problem than overly complex conditional expressions. As you point out, adding a well-named function or variable that summarizes a series of tests is more important.

        Since we've probably all seen these same kinds of confusions in languages that do not have an unless, it seems more reasonable to focus on clear conditionals rather than which keyword is used. If the conditional expression is clear enough, the code will be clear.

        G. Wade
Re^4: Burned by precedence rules
by GrandFather (Cardinal) on Dec 26, 2008 at 20:45 UTC

    I absolutly agree that unless often becomes very confusing with more than one element in the condition and almost always use if in that case.

    I'm in (southern hemisphere) holiday mode at the moment so my head isn't fully in Perl space. I focused on the two nots rather than the 'and' and actually in the specific case given I think the result conveys the intent better than the if version - no De Morganizing required.


    Perl's payment curve coincides with its learning curve.
      Yes, it reads nicely. But if you're debugging and know the two values, you may be very surprised at what it does. By contrast in that mode you will reliably figure out what the if version does.

      If you can easily run the code this is not so bad, But in my case I was debugging a failure in a batch job that failed after hours of work. In code I hadn't touched in months. Hence my failure to correctly figure out whether the conditional was executed lead to enough pain that I learned my lesson. The if version may not be pretty, but it is just as understandable when coding and a heck of a lot easier to debug. So use it.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://732634]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (8)
As of 2014-10-21 02:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (95 votes), past polls