Re: Operator Precedence

[AidanLee]

I'm afraid I have to disagree. I would propose Yet Another dogma (familiar to most I am sure):

"everything in moderation"

While I'll say it is great you have expanded your own knowledge to have memorized the precedence table, That doesn't mean that everyone reading your code will take that same initiative. Unless you are coding soley for yourself or know the exact audience of maintainers you will not be able to rely on the skill/knowledge level of those who work with your code. Consider especially if you were to submit something to CPAN!

Even beyond the matter of skill level, I'd have to agree with Masem that it's easier to SEE at a glance what a certain statement is trying to do with a few well-placed parens. For me it is usually a matter of visual grouping over forcing precedence and I often code per Masem's third example because it self-documents the coder's intent, while the first two do not.

[jynx]

It's slightly redundant, but saying the second half of that phrase is helpful:

Everything in moderation, including moderation

There are going to be coding projects where you'll want to document every line and use parentheses liberally, and there will be the counter-projects where everything is fast and loose and you want it to get done more than you care about maintenance*. Whether these are professional or personal projects doesn't matter, it's just important to note that sometimes you shouldn't moderate your own behavior because you think that one way is the right way to do things. Remember that this is Perl we're talking about, which is all about TIMTOWTDI.

The apprentice moderates all his actions, while the master knows when to not moderate his actions as well...

HTH,
jynx

^*This is of course in addition to the standard projects which should be documented "in moderation" (well, but not too well ;)

[tomazos]

I think we would all agree that documenting every line of your code (with parens, formatting, spacing, pod, comments etc etc) is too much:

$a = 3;  # Set the global variable called a (which is a scalar variable, meaning that it can hold either a number or a string - in this case we are using a string) blah blah...

Is not a "moderate" amount of documentation.

Writing your entire program on one-line is also not a "moderate" amount of documentation.

So somewhere in between the two extremes lay a "moderate" amount of attention to readability and documentation.

My statement is that at that point of moderation - in most professional environments - it *should* be expected that the reader knows the precedence table - and therefore documentary parenthesis are not necessary.

[Cubes]

The trouble with basing decisions on how things *should* be is that so often things are not as they should be.

Heck, I'm happy when co-workers can comprehend basic office ettiquette and the boss doesn't expect me to teach everything I've learned in the past 15 years to the new guy in 15 minutes. If I expected the person reading my code to have as firm a grasp of the precedence table as you, I'd be disappointed more often than not.

The sad reality is, in much of the "professional" world, budgets are too small, deadlines are too soon, and managers don't give a hoot what your code looks like on the inside as long as it gets the job done. Call my extra brackets False Laziness if you want; I call it an extra bit of insurance against one more brain-fart bug -- one that I don't have time to track down and fix -- creeping into my code.

Good for you for questioning things, especially in public. We need questions like this to remind us to take a good look at how and why we're doing things the way we are. Unfortunately, there are times when the best answer I can give is "because I have to."

(OK, I don't really *have* to, but I'm not quite willing to give up my paycheck to crusade against extra brackets in perl code :-)