Hello stevieb,

I agree with Your Mother, remove all parens that are unnecessary for the compiler, and I think this brings up an interesting point.

I first came to Perl from C++, and one of the strengths of Perl is that it lets programmers who are familiar with C and its derivatives come up to speed slowly. We can begin by writing Perl as though it were C, only gradually learning Perl as a separate language. So, my first scripts had C-style (3-argument) for loops, and when I came to learn the Perl foreach construct I of course spelt it foreach to make clear to me that I was using a different syntax. But over time the new syntax became familiar, and now I follow standard practice in (a) preferring foreach-style loops to C-style loops wherever possible, and (b) using the for keyword for either construct.

In a similar vein, I used to write length($string) but now more usually omit the parentheses: length $string. It took me a while to become comfortable with the more idiomatic Perl syntax, but now I prefer it: simpler is better. As a rule, I use statement modifiers where feasible and prefer the default variable ($_):

/^$/ or print for @strings;
[download]

is simpler and better than

for my $s (@strings)
{
    print $s unless $s =~ /^$/;
}
[download]

But this raises the interesting point: Is my code now more or less readable? More or less self-documenting? And the answer is: It depends on who is reading it. If an experienced programmer who was familiar with C but new to Perl were my code’s intended audience, he would find the more C-like constructs easier to follow. But for an experienced Perl programmer, the more idiomatic code is easier to read, not only because it is more concise (which is a big plus), but because it is what he expects to see. He isn’t continually asking “Why did he do it the roundabout way?” as he wades through my code. If my code is well-written, its rationale should be obvious.

So, should one write code for the novice or the experienced Perl programmer? I suppose that depends in part on the sort of workplace one has; but in general it seems common sense to me that one should write code idiomatically, to be comprehended easily by Perlistas rather than by newbies. And the reason is this: by writing Perl idiomatically, we automatically benefit from those features of the language which constitute Perl’s strengths. Further, Perl is a language, so mastering Perl means not only understanding its syntax — to communicate effectively with the compiler/interpreter — but also communicating effectively with one’s fellow Perl programmers. And in communication, simpler is better.

So, as Your Mother implies, if a construct is unambiguous to the compiler, it’s a good rule of thumb that it will be likewise unambiguous to experienced Perl programmers — and they should be the code’s intended audience. (The one exception to this rule is the use of parentheses to clarify order of precedence in complex logical or mathematical constructs. I prefer to use parentheses here even when they’re not strictly necessary. I’m not sure if that’s a good or a bad thing.)

Hope that helps,