Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: Operator Precedence

by MrNobo1024 (Hermit)
on Jul 22, 2001 at 20:02 UTC ( #98831=note: print w/replies, xml ) Need Help??

in reply to Operator Precedence

"I noticed an interesting thing in doing this. Usually you don't need to use brackets at all. The precedence table was designed in a clever way so that most of the time if you are writing your code clearly, you don't need to change precedence at all by using brackets."

That's usually true, but then shouldn't $f ^ $g == 1 be equivalent to ($f ^ $g) == 1?

Replies are listed 'Best First'.
(tye)Re: Operator Precedence
by tye (Sage) on Jul 23, 2001 at 04:25 UTC

    Yes, it should. The fact is that the precedence of the bitwise operators is broken and this will finally be fixed in Perl6 (this has been broken since C).

    I agree that most of the time you don't have to worry much about precedence because it was well designed. There are a few exceptions:

    1. Bit-wise operators. They should bind tighter than comparison operators but don't. How they should bind compared to arithmatic operators is not clear but I find it never turns out the way I'd like. So I pretty much enclose all bit-wise operators (including shift operators) in parens and when I forget to do that I usually get bit by it.

    2. Putting assignments in expressions. Although     $bool=  $x == $y;
      is probably less common than     if(  0 == ( $cnt= get() )  ) {
      the fact remains that assignment binds more loosely than nearly anything so those parens in the second example are required.

    3. Don't do     open IT, "< $it"  ||  die "Can't read $it: $!\n";
      because you should use or for that instead.

    As for adding parens to make the code more readable, my personal preference is to use whitespace instead. Perhaps it is just me but I don't find nested parens at all easy to match up with the naked eye. But if I have a long expression with some parts separated by single spaces, other parts separated by double spaces, and maybe one triple space, I find the grouping obvious. If I need to go to more than three levels, then I probably need to throw in some intermediate named variables to make the code easier to read anyway.

    Even in something like (0 <= $x) && ($x <= 10), I find that the parens do a very poor job of conveying the grouping. The "(0" looks more like a group because of the spacing. /: That is why I always put spaces inside my parens: ( 0 <= $x )

            - tye (but my friends call me "Tye")

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://98831]
[Cosmic37]: I wish thee a peachy life and express gratitude for considering my pathetic questions
[erix]: record separator
[Cosmic37]: Permissions are interesting earthlings. Did nature determine who gives permission and who asks permission. Who was the first to get permission? Are you not related to them as one big earthling family?
[karlgoethebier]: Cojones! We need cojones!
[karlgoethebier]: Ouch! Permissions! We need permissions!

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (8)
As of 2017-06-29 16:39 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (672 votes). Check out past polls.