Learning how to use parathesis less and operator precedence more is, IMO, equivalent to the progress one makes in their prose writing as they advance through school. Sentence structure become more advance, less common words are used more, etc. This is partially due not only for the writer to able to convience his/her message better, but reflexively, for the writer to review and critique their own work. If the writer users structure and words too complexe for them to understand, they usually go back and change it. For example, a common example is the compound sentence; it's nearly always better to go back and break that into multiple sentences if the meaning is not readily understood. However, well-written prose writers can effectively use complex sentences because they have learned the subtlies needed to help readers parse and understand the sentence correctly.

With any language with operations, the same is true; the typical pattern is for most new programmers to parathesize every expression so that the programmers him/herself can understand what the code does when they review it again. But as the coder progresses, and understands where parenthesis are unnecessary, they will start to avoid them, sometimes resulting in cleaner code that still can be understood by all. But there are still times that I would consider using parenthesis in order to convey understanding in a program even though I could not use them and get the same expected result. For example, to test whether a point ($x, $y) might be in a bounding box, I could use:

if ( ($x >= $x_min ) && ($x <= $x_max) && ($y >= $y_min) && ($y <= $y_
+max) ) { ... }
[download]

if ( $x >= $x_min && $x <= $x_max && $y >= $y_min && &y <= &y_max ) { 
+... }
[download]

if ( ( $x >= $x_min && $x <= $x_max ) && ( $y >= $y_min && $y <= $y_ma
+x ) ) { ... }
[download]

But a lot of this boils down to personal preference, the coder's workplace environment, and how much maintainence and code upkeep will be done when the programmer is long gone. If I was in a shop with several perl newbies, I'd be tempted to use option 1 above over option 3 as a new programmer would understand it better (breaking the complexe into several smaller parts). But if the code was only for my use, it would most likely be 2.

So learning the operator precedence table is important. Knowing how to use parenthesis is important. But one of the defining qualities of a good programmer is one that knows how to combine these aspects into code that easily flows from the perverbal page to the reader's mind without syntax getting in the way. Removing all parenthesis for less characters in a file is a nice worthy goal , but the end result may not be as clear as one that uses just the right amount of parenthesis to help convey meaning.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

I guess a corollary of my meditation is that programmers may be purporting to use paranthesis to help document their code, where in fact they are using them because they have not bothered learning the precedence table - and using them "just to be safe".

Once you know the precedence table, this:

$x >= $x_min and $x <= $x_max and $y >= $y_min and &y <= &y_max

...looks the same as this...

($x >= $x_min and $x <= $x_max) and ($y >= $y_min and &y <= &y_max)

...and is no easier to read. In fact I would go so far as to say the last example is slightly harder to read because of the extra parentheses.

In short, I think that no reader benefits from "documentary" parenthesis if they know the precedence table - and a programmer that doesn't should be told to spend the few hours it takes to learn it - rather than the rest of us constantly worrying about them when we code.

Precedence is not the issue in comparing

$x >= $x_min and $x <= $x_max and $y >= $y_min and $y <= $y_max
[download]

with

($x >= $x_min and $x <= $x_max) and ($y >= $y_min and $y <= $y_max)
[download]

Neither will work if and has higher precedence than &lt;= and &gt;=!

The issue with the extra brackets here is to add a structure to the code that simplifies understanding. Instead of having to understand 4 independent logical tests, I have to understand 2 logical tests, then combine them. And once I've worked out the first test is "$x is between $x_min and $x_max", the second test is much easier to work out.

An alternative way to produce the division is simply by using a line break:

$x >= $x_min and $x <= $x_max and
$y >= $y_min and $y <= $y_max
[download]

also makes the analogy easier.

In any case, a much nicer way to write an interval test (if you're worried about readability) is to put $x on the inside, and keep all comparisons using the same direction:

$x_min <= $x and $x <= $x_max and
$y_min <= $y and $y <= $y_max
[download]

I agree that there are cases where a programmer will use extra, unneeded parenthesis as to avoid any problems with the operator precedence table, and to be truthful, I don't know it by heart. But there are cases that I know for sure (e.g. that boolean && and || take precedence over inequality operators, or that = is weaker than =~), and I'll take advantage of them when possible. And, more importantly, I know where to find this table if I absolutely need it to understand code. (This is my biggest piece of advice that I can give from going through an engineering advanced degree: it's not what you know, but knowing where you can find it if you don't know.).

I think the assumption that no reader benefits from documentary parens is assuming that all code readers are highly skilled in the first place, and this is obviously false. Programming is a multifaceted skill, and not only requires writing good code, but being able to read code, though this is a skill that I've seen lax in CS education. Even a newbie programmer that has taken the time to learn the precedence table may find themselves stuck on code that lacks any other 'aids' for understanding, either in the form of comments or grouping parens.

That said, I think it's important moreso to present code as close to prose as possible rather than to distill it down to a mechanical efficiency, because we has humans tend to think on the language level rather than the mathematical one. And typically with languages, the way the mind works is to soak in phrases and small sets of words instead of either the entire sentence at the whole time or each individual word, so presenting thoughts in concise but descriptive bits can provide the maximum transfer of information from the page to the mind. For example, in the first statement I have above, I have several concise phrases but only until I've read the entire line is the meaning clear because I had to go back and think about what the interplay between the various phrases are. In the second, I cannot identify such phrases, so I take it in chunks; the meaning is still there, but from a mind's eye, parsing it is not apparent. The final example has two obvious and concise phrases, *and* both are very descriptive; I know that I'm looking for $x between two values and $y between two values. I would think that most readers would understand the intent of this code faster than the other cases. Of course, not everyone is average, and it is apparent in your (tomazos's) case, that your mind focuses not on the phrases as donated by parens but on the operators and variables. Thus, you might find your understanding improved by reducing the extra weight of parens.

However, before you go stripping all the parens from your code where needed, make sure you understand what the intended audience of the code is. Your workplace may have programming guidelines that override these. If you have to share code with cow-workers who think more in the overall meaning than the individual pieces, they may become annoyed with you everytime a new piece of your code shows up for development. If you give your code away and don't expect anyone to look at it until after you have long left the site, is the code sufficient enough to stand on its own without your input for others to understand? Of course, anything that is completely for your own benefit, you can do what you want, but if more than a few sets of eyes will ever look at the code, it's better to aim for a treatment of the code that will satisify the bulk of those that look at it, even if it means that the code doesn't look good to you.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

I claim that the two conditions don't look the same. They do to the compiler of course, but not to me.

In this case the second tells me the intent of the command whereas the first only tells me the command.

The purpose of the extra parentheses isn't to instruct the compiler, it is to instruct me. And it's not to instruct me in what specific sequence of operations the compiler is being told to execute, but to tell me something about the real problem being solved, i.e. 'is the point in the box?'.

And this is a diferent question than 'Is X both less than the maximum x and greater than the minimum x while at the same time, Y is less than the maximum y and greater than the mimimum y?'

You may ask, well, if the compiler thinks they're the same, then what's the difference? Or you may not, but let's assume you did. :)

I answer that source code is meant to be read by the compiler *and* humans. It therefore must serve two purposes, to correctly instruct the processor in the sequence of operations to be performed, and to instruct the human who reads it.

Many humans find 'Is the point in the box?' far more digestible than 'Is X less than ... and ... and ... '

For me, the 'documentary' parentheses make if far easier to see the question as an instance of the first and not the second.

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";
[download]

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);
[download]

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.
[download]

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";
[download]

cheers

tachyon

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

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.

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.

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.

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 ;)

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.

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 :-)

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.

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};
[download]

(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...

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

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")

What is the difference between 5 + 4 / 2 and (5 + 4) /2?

What is the difference between being explicit, and implicit?

What is the correlation between implying and assuming?

 
___crazyinsomniac_______________________________________
Disclaimer: Don't blame. It came from inside the void
perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

1) Precedence tables are not consistant across all languages
2) Precedence tables are subject to change in non-standardized languages.

While there has been an obvious effort to keep the main operators (arithmetic, in particular) consistant and based off of the mathematic precedence table across most languages, when it gets down to things like bitwise ops there is a lot of room for difference. I can't think of an example right offhand, though.

~Cybercosis

nemo accipere quod non merere

Perl is all about using (private) idiom to match personal style and increase efficiency. So in that sense I agree, example 3 seems easier to understand (to me). I think I've probably used all three examples in similar situations depending on how I thought about the problem, which is the point.

But the other two examples would be fine too if separated by whitespace/linefeeds, depending on temperament. This is a question not of how well someone knows precedence but about personal style. I am not sure that your personal style depends more on precedence rules than some other people here.

That said, I lost faith in the infallibility of precedence rules when I heard they were going to be "redefined". Maybe there is a fine (subjective) line between common knowledge and the esoteric in this case but as you can see from the comments everyone comes at Perl from a different angle and often there are good reasons for not exploiting that knowledge.

Just thought I'd add this paragraph from Larry Wall's Natural Language Principles in Perl. I guess you could take it either way, but in the end I guess your own predilection is going to decide whether you find coding for ordinary folks useful or not. Anyway.

No theoretical axes to grind

Natural languages are used by people who for the most part don't give a rip how elegant the design of their language is. Except for a few writers striving to make a point in the most efficient way possible, ordinary folks scatter all sorts of redundancy throughout their communication to make sure of being understood. They use whatever words come to hand to get their point across, and work at it till they beat the thing to death. Normally this ain't a problem. They're quite willing to learn a new word occasionally if they see that it will be useful, but unlike lawyers or computer scientists, they feel little need to define lots of new words before they say what they want to say. In terms of computer languages, this argues for predefining the commonly used concepts so that people don't feel the need to make so many definitions. Quite a few Perl scripts contain no definitions at all. I dare you to find a C++ program without a definition.