I'm inclined not to follow this. I don't like to rely on subtle precedence rules. Is there any reasoning to not always use parentheses instead?

(This is a quite generic question, applying not only to Perl, and so the answer does not only apply to Perl.)

There might be reasons, I guess the most common ones are avoiding typing and cleaner code.

And I think both do not apply, for exactly the reason you gave: "I don't like to rely on subtle precedence rules."

Treating operators as having completely random precedence, except for parentheses and the "multiplication and division before addition and subtraction" rule definitively prevents nasty surprises with operator precedence. Adding parentheses does not hurt, the compiler or interpreter should need just a few CPU cycles to handle them. Parentheses clearly indicate the programmer's intended order of evaluation, without forcing the next programmer to memorize precedence rules.

Example:

if (a && b || c && d || e) // wtf? Don't make me guess what you intend
+ed!
if ((a && b) || (c && d) || e) // clear
if (a && (b || c) && (d || e)) // as clear, but a very different condi
+tion
if (a && (b || (c && (d || e)))) // a different condition
if ((((a && b) || c) && d) || e) // another different condition
[download]

My current job is developing embedded software for medical and aerospace devices. We have a very strict rule that parentheses are required whereever code might be ambiguous. The first example would never get through the obligatory code review; you will never find that in production code.

And by the way: If you are working with several languages, as I do, you will notice that precedence rules vary from language to language. Most copy or inherit from C, but some are very different. MUMPS evaluates strictly from left to right, unless parentheses are used. In MUMPS, WRITE 1+2*3 writes 9, not 7. WRITE 1+(2*3) writes 7.

Of course, redundant parentheses are rubbish:

if ((((((((a && b))) || (((c)))))))) // make extra-sure that parenthes
+es have precedence ;-)
[download]

Some times, lots of parentheses are required, adding some white space and indention clearly helps:

if (
    ((a == A_MAGIC_1) || (a == A_MAGIC_2))
    &&
    ((b == B_MAGIC_1) || (b == B_MAGIC_2))
    &&
    (
        (c == C_MAGIC_1) 
        || 
        ((c == C_MAGIC_2) && (a == A_MAGIC_2) && (b == B_MAGIC_2))
    )
)
[download]

Yes, this will make the C compiler "waste" about thirty precious CPU cycles eating up all of that redundant white space and braces. Just think how long that takes at 3 GHz! And it gets worse, because all of the source code "wastes" CPU cycles. So compiling the enitre project takes 1.5 msec more time than needed. Flashing into the target takes 20 +/- 2 seconds. Deciphering source code "optimized" for better compile times takes minutes per line, hours per file, every time a change is required. This is a real waste of time and money. Computers and compilers become faster every day. A modern desktop runs circles around old super computers even with crap components. "Optimizing" source code for compile time is ridiculous, except in very rare high-performance cases.

Alexander