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.

There's never any GOOD reason to go leaving parens out. Not on maintained code, anyway. See the story on nuclear missiles and Perl.. with the mistake being blamed on an ASSUMED precedence order on an operation. Even in this example use of parenthesis would have given this user the compile time warning he was looking for. Even smarter would be to add argument expections to the prototype: sub chk_timer( $ ); But programmers like to think they are smarter than that and take risks. So do a lot of American drivers refusing to wear their seatbelts. That's ok, an ego is a precious thing, except in professional circles. If you can't program to protect against yourself, or drive wearing a seatbelt JUST IN CASE, then you have no defence when you look silly (or dead) at the end of the day. The art of programming is like self defence, mastery of self. I am not perfect.. are you?

There's never any GOOD reason to go leaving parens out. Not on maintained code, anyway.

Really? Are you sure?

   open IN, '<', $infile
      or die "Cannot open infile: $!\n";
   my $foo = <IN>;
   print "The foo value is " . $foo . ".\n";
[download]

Or would you prefer to see it this way...

   ((open(IN, '<', $infile))
      or (die "Cannot open infile: $!\n"));
   ((my $foo) = <IN>);
   (print(("The foo value is " . $foo) . ".\n"));
[download]

As someone who has programmed in lisp, I can handle working with code like that, but it's not the most clear and Perlish style available. Some of those (parens (aren't (strictly (necessary)))), because the order of some operations is so well-established and obvious that the code is clear without them.

---

"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68