Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re (tilly) 1: Operator Precedence

by tilly (Archbishop)
on Jul 23, 2001 at 05:23 UTC ( [id://98893]=note: print w/replies, xml ) Need Help??

in reply to Operator Precedence

Let us do a little cost-benefit analysis.

If you invest a few hours of work in memorizing the operator precedence table and keep on using that knowledge so that you don't lose it, then you will know that table. This has three good effects. The first is that you are now able to read code written by people who don't use parens. The second is that you can write code which is marginally clearer to people who have made the same investment. And the third is that you get a feeling of accomplishment.

But note that all three wins only work if you are dealing with people who have all done the same thing, and you yourself constantly use Perl and not only use Perl, but use your knowledge of the precedence table so that it does not get rusty.

As many people here have pointed out, this does not help you if you are surrounded by people who have not learned the precedence table. It does not help you if you work in multiple languages and so do not have the luxury of remaining up on Perl trivia. It will not work so well when you go from Perl 5 to Perl 6 and the precedence table changes. It does not help you if you have co-workers who need to follow your code but are in any of the above situations. And you will lengthen the path to training a new person in your environment.

My attitude is simple. I think that a company should have a list, formal or informal, of features which they use. There is enough to Perl that just abusing all of the syntax everywhere is going to be a nightmare, try to stick to a subset that multiple people can understand and maintain. I already have a lot that I put on that list. The list-oriented nature of Perl. Basic REs. The OO features. Closures. And (particularly given the needed ongoing maintainance of the skill) the operator precedence table just doesn't make the cut for me.

Replies are listed 'Best First'.
Re: Re (tilly) 1: Operator Precedence
by tomazos (Deacon) on Jul 23, 2001 at 07:01 UTC
    Firstly, I think you have understated the positives of knowing the precedence table somewhat.

    Secondly, even with the weight of the three positives you have mentioned, and no one is claiming any negatives to learning it. So the question is do the positives outweight the time investment of 2-3 hours? For anyone reading this I would say the answer is almost always yes.

    I think my original statement has become a little side-tracked. My meditation is to memorize the precedence table - something a lot of us (even some of the best programmers) have not done.

      Please read, for a random example, the thread at RE: RE: Shot myself in the foot with a pos. My position from before when I arrived at PerlMonks is the same as it is now. There is a lot of stuff which I know that I rightly don't expect fellow programmers who are not primarily Perl programmers to know.

      This is not a position that everyone agrees with me on. Not even, by a long shot, all good programmers. (If you know anything about who is who in the Perl world, then you will know who chip is.) However in the real world there is a lot to say for my position.

      As for your position, huh? Do you really think that I have never looked at the precedence table? The fact that I don't advocate gratuitously abusing knowledge of it should not be taken as a sign of ignorance on my part. It is rather narrow-minded of you to assume that everyone who disagrees with you is more ignorant of this aspect of Perl than you are.

      Besides which, your assumption is wrong.

      My dislike of gratuitous abuse of operator precedence goes hand in hand with my dislike of using explicit positional logic when you don't have to. It is the same thing that leads me to write modularized code when I could write straight-line code for the task at hand. It has nothing to do with any inability on my part to do the things which I am avoiding. Instead it is my attempt to apply the principles that I believe lead to the most maintainable code for the environment that I am in.

      Now do I think it is useful to know the precedence table? Well yes. Knowledge is always good It is good to not be confused by quirks like the following:

      my %foo = "Hello", "World; print $foo{Hello};
      (Of course if you use warnings you will be pointed at the error without having to have the precedence table memorized. Funny how that works...)

      But I don't think that people should have to have the precedence table memorized to read my code. There are enough other things that they need to keep in mind which I consider more important...

Log In?

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

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (2)
As of 2024-04-21 20:52 GMT
Find Nodes?
    Voting Booth?

    No recent polls found