my $do_munge = $foo->is_ready() and $foo->needs_munging();

return $foo->is_ready() and $foo->needs_munging();

$count += $foo->willing() and $foo->able();

push @passes, $foo->tried() and $foo->success();

$separator = $args->{separator} or ',';

skip_if( $not_mocked or $in_prod, sub { test_stuff() } );

LOG "Failure to launch.", because => $!, 'retry?' => $retries_left and
+ $not_fatal;
[download]

Thanks for that.

For a decade or more I've habitually used and/or/not over &&/||/! in most situations in my code and, whilst I recall having encountered a handful or less situations where the precedence was wrong for my intent the first time I ran the code; I don't recall any occasion where it was something that I didn't discover at first run, or had any trouble locating and fixing. No latent bugs or deeply disguised issues that took any great effort to track down and fix.

My feeling, without trying to put any great store in the accuracy of that feeling, is that I've been bitten (far) more often by the high precedence versions than the low. Mostly Perl warns me about them, but one or two have taken some effort. Of course, now I should respond in kind with examples; and I've racked my brains and can't reproduce anything that is a good example. I'll come back if I rediscover any of them.

Please note, I'm not really arguing with your POV; just noting that my own experience doesn't reflect the strength of feeling you have on the subject.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

strength of feeling you have on the subject

It may come across that way more strongly than I feel it because, as usual, I try to consider potential readers and try to anticipate counter arguments or how they might misinterpret what I've written and that often leads to me belaboring the point more than would be optimal (even after I've gone over it all again trying to drop parts where I've gotten repetitive).

I've been bitten (far) more often by the high precedence versions than the low. [...] I've racked my brains and can't reproduce anything that is a good example.

As part of reviewing stuff as part of participating in this thread, I did remember a much more recent bug that made it to Prod where it was immediately noticed and then fixed. In cleaning up some code, a construct similar to:

my $log_file = 
        $CmdOptLogFile
    ||  $DefaultLogFile;
[download]

Ended up actually being like:

my $log_file = 
        $CmdOptLogFile
    ||  $CmdOptViaCron ? $CronDefaultLogFile : $DefaultLogFile;
[download]

So the common use of '||' not for a Boolean expression but for providing a default value helped me to forget that '?:' expects to take a Boolean expression as its first argument and so binds more loosely than the normal Boolean operators. One could use 'or' here to avoid using parens to fix that particular problem. But now that I've said that, I realize that using 'or' would then introduce a new problem that would require adding a different set of parens (I hadn't realized that at first because when fixing the bug I didn't really consider using 'or' because this was not a case of "flow control between statements", as is my "best practice"). So, sorry for somewhat ruining my gift example. But maybe it helps you to remember an even better example.

situations where the precedence was wrong for my intent the first time I ran the code; I don't recall any occasion where it was something that I didn't discover at first run, or had any trouble locating and fixing. No latent bugs or deeply disguised issues that took any great effort to track down and fix.

My experience was mostly just finding latent bugs. They certainly were not deeply disguised and they did not take great effort to track down. They were all cases of looking at code and noticing that the real meaning of the code didn't seem to match the intent (in part because similar precedence problems were fresh on my mind). And these particular ones were all things that nobody was complaining about. The actual change in behavior due to these bugs were so rare (due to the particular combination of 2 or more conditions that had to be met for the bug to be triggered) that nobody was looking for these bugs.

But I also would not have been the one to experience "I used 'or' and then noticed I had done it wrong" because I was not using 'or' for Boolean expressions. So it isn't surprising that the only bugs I ran into were the ones that didn't cause any serious or frequent problems. But I was actually at least a bit surprised when I did find such bugs. The clincher for me was when I looked at the commit history for the most interesting bug and found that it was written by the most experienced Perl developer on the team (I'm not sure if he has more or less experience than me with Perl, though I'm pretty sure I have more programming experience just because I'm quite a bit older).

That was what switched me from "I think using 'or' for Boolean expressions is a bad idea and should be discouraged in our style guide but other team members find them prettier" to being able to make the case more strongly to get it into our style guide.

I elaborated on some stuff but reading over it again it seems rather unlikely to be of much interest. I include it below just in case some haven't heard plenty on this topic already.

Read more... (3 kB)

- tye