Re: Operator Precedence

[tachyon]

In Perl there are many ways to do it. In production code the reality is that someone with less experience/knowledge/patience than you may one day have to maintain your code. Sure you can do it in one line. Sure you don't need brackets, or pod or comments or long var names..... to make your code run. We add all these things to make the code easier to debug, easier to understand, and easier to maintain. With parenths precedence is a gimmee, without it may not be. Perhaps one of the commenest problems I see on PM is why doesn't this work:

open FILE, "<$file" || die "Oops $!\n";

Sure all you need to do is add brackets or change the || to 'or' but this is not obvious. This aside I find code like this:

print ("Hello World!\n");
close (FILE);

anoying as there is no precedence issue being addressed by the brackets - probably just a C hangover. There are however some problematic examples like:

/foo/ ? $a += 1 : $a -= 1;
# parses as
(/foo/ ? $a += 1 : $a) -= 1;
# but
$a += /foo/ ? 1 : -1;
# will work as expected.

Shorter is not always better. Never expect anyone to understand what you are trying to do as well as you do. Adding parenths takes a fraction of a second if you touch type. Sure don't go overboard but save your precedence expertise for GOLF. Personally I vividly recall precedence issues causing *interesting* bugs. I felt sure that I knew the precedence until I stepped through the code and realised Perl and I did not share the same views! This said brackets are not always good, consider these examples - the last fails.

$_ = 'foo';

/foo/   ? print "Found foo\n" : print "No foo here\n";
(/foo/) ? print "Found foo\n" : print "No foo here\n";
print /foo/   ? "Found foo\n" : "No foo here\n";
print (/foo/) ? "Found foo\n" : "No foo here\n";

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[tomazos]

The solution to *interesting* precedence bugs is not to throw in parenthesis for no reason. A prevention is always better than a cure. The examples you have given are a demonstration of my point. Why do you think the ternary operator has higher precedence than assignment?

Because:

$is_good ? $white : $black  += 1;

Yes, to someone who doesn't know the precedence table this is confusing. To someone that doesn't know any Perl I'm sure that the Howdy World program is confusing too. The solution is not to document every line in painful detail as to what exactly is going on so that people that don't know Perl can read your program.

The solution is that programmers learn the precedence table and soon what seemed like a cryptic and convoluted expression will magically transform into an obvious sequence of calculations.

[pmas]

I have to slightly disagree with you, tomazos. I feel slight tendention toward elitism, like in: "if you cannot learn to perfection precedence table, you are not good enough to understand my code, so damn you...". Sure I exagerated a lot to show my point, but just think about it.
My situation is very different from yours. In our team, about half team memebers have biology or medicine background, not computer sciences. Some (not all!) are struggling with programming, but for every one time I wish they know some rare trick, there are three times I am amazed what they know about problem domain, how they can understand what customer is saying, what I might understand wrong without their help. Parts of old system are in ASP, simple "database proof of concept" is done in MS Access, some people just know PHP and prefer it (not me!), but htey may ask me to look at their code (to solve database isuues). So this is not only issue of "learning perl precedence by heart", real life is not this simple.

So my point is: when thinking about parantheses, err on side "more () for better understanding", and avoid "for expert of my level this is obvious". Generations maintaining your code will thank you for that.

pmas
To make errors is human. But to make million errors per second, you need a computer.