I find code having as few parentheses as possible to be best readable.
Depends. There are some situations where parens add clarity, and there are others where they don't. Generally speaking, if there's a significant potential for someone's not having memorized the precedence table to result in confusion, it's better to include the parens, but otherwise you can leave them off. Obviously, different people have different threshholds for how divergent the precedences in question have to be before the potential to misread is sufficiently small to justify leaving off the parens, but I think in principle most of us can agree that there are some pairs of operations with a very similar precedence, in which case the parens add clarity, but there are other pairs of operators that have such markedly different precedence that any clarity the parens add is extremely marginal and not worth the tradeoff. It becomes a question, then, of where to draw the line.
A good example of the latter scenerio is when you're using the loose-binding spelled-out logical ops to join together expressions containing tightly-bound operators, as in $foo .= <BAR> or return $foo;. Nobody with significant Perl experience needs parens to help them through that one. On the other end of the scale you can have expressions that include bitwise operators and other relatively obscure ops for which many people don't remember the precedence. In those cases, the parens are a Good Idea.
In reply to Re^3: Warning for "unused sub declarations"?
by jonadab
in thread Warning for "unused sub declarations"?
by blazar
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |