And if your memory is faulty like mine, and you can't remember a zillion precedence rules for various languages if your life depended on it, adding extra parens is the key.

I disagree. In fact, I disagree that you should even try to learn the precedence rules (for Perl, at least). Larry et al put effort into ordering the relative precedence of the operators so that most of the time they will Do The Right Thing, without you having to think about precedence or parens.

Your claim of having a "faulty" memory suggests you think that 'better' programmers have memorized all the rules. If knowing the rules was the only sane way of using the operators then precedence could be entirely arbitrary (or alphabetical, or non-existent, with everything at one level and being processed from left to right); it doesn't matter what the order is, cos it's just one of those things everybody has to learn by rote.

But the whole point of precedence is to make life easier for programmers, so that operators naturally behave themselves. Treating precedence as some random list to be memorized is shunning this help and making life harder for yourself.

Arguably what tripped up the original poster in this situation was using the wrong operator: not, rather than !. Knowing the operators and what they are intended to be used for is definitely worthwhile.

I honestly didn't know the relative precedence of the operators mentioned in this thread, but I'd've happily coded using them, trusting Larry to have got them right. And ditto for associativity.

It sure does seem like wimping out though...

And adding extra parens can often make code harder to read. If I'm skimming through some code at speed trying to get an overview of what it does and I see a long expression without any parens then the expression probably isn't doing anything out of the ordinary and does what I expect it to do without spending much time thinking about it.

But if I encounter a long expression with parens in it then the parens are overriding the normal precedence rules: the statement is doing something funky, so I'd better pause and read it. Moreover, working out exactly what involves matching up all the pairs of parens.

Now it may turn out that the statement does exactly the same as if it hadn't been liberally sprinkled with parens, but it's impossible to tell that at a glance: two statements that differ just in the location of one paren may do very different things but look almost the same to a passing human eye, whereas a statement that has no parens in it is clearly and readily distinguishable from either of them.

Trust Larry more! Use parens less!

Smylers