|Think about Loose Coupling|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
Let us do a little cost-benefit analysis.
If you invest a few hours of work in memorizing the operator precedence table and keep on using that knowledge so that you don't lose it, then you will know that table. This has three good effects. The first is that you are now able to read code written by people who don't use parens. The second is that you can write code which is marginally clearer to people who have made the same investment. And the third is that you get a feeling of accomplishment.
But note that all three wins only work if you are dealing with people who have all done the same thing, and you yourself constantly use Perl and not only use Perl, but use your knowledge of the precedence table so that it does not get rusty.
As many people here have pointed out, this does not help you if you are surrounded by people who have not learned the precedence table. It does not help you if you work in multiple languages and so do not have the luxury of remaining up on Perl trivia. It will not work so well when you go from Perl 5 to Perl 6 and the precedence table changes. It does not help you if you have co-workers who need to follow your code but are in any of the above situations. And you will lengthen the path to training a new person in your environment.
My attitude is simple. I think that a company should have a list, formal or informal, of features which they use. There is enough to Perl that just abusing all of the syntax everywhere is going to be a nightmare, try to stick to a subset that multiple people can understand and maintain. I already have a lot that I put on that list. The list-oriented nature of Perl. Basic REs. The OO features. Closures. And (particularly given the needed ongoing maintainance of the skill) the operator precedence table just doesn't make the cut for me.
In reply to Re (tilly) 1: Operator Precedence