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