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.
| [reply] |
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.
| [reply] |
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.)
| [reply]
[d/l]
[select] |
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) ) {
| [reply]
[d/l]
[select] |
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.
| [reply]
[d/l]
[select] |
In that situation I use unless as well. But I flip to if when I need to add and or or.
| [reply] |
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.
| [reply] |