confuseAcat

I am currently reading through "Effective Perl Programming". Another fine book that I wish my coworkers would read. (And another fine book they are not going to read). The authors not only want you to write effectively, they want you to write concise code that is easy to read for anyone with a bit of Perl experience. For example, there is a piece of advice in there that says "Avoid excessive punctuation": "[...] Excessive puctuation makes programs less readale [...]" Exactly!

But why is code less readable when it's full of parenthesis, e.g.? I think the answer is simply that the puctuation lowers the signal-to-noise ratio. When reading code, you are looking for the signals, the statements that actually do something, the meat, the beef. A corollary of this is that a bit of whitespace here and there will increase your code's signal-to-noise ratio because it will make the beef stand out.

Here's a stupid little example:

$x=foo();
if(defined($x)) {
    bar($y,$x,$z);
}

That's pretty cramped code and whitespace will make it more readable:

$x = $foo();
if ( defined( $x ) ) {
    bar( $y, $x, $z );
}

It's a lot easier to see what is is that needs to be defined here and what the arguments passed to bar() actually are.

Now, assuming this is possible here, let's get rid of the excessive punctuation:

$x = foo;
if ( defined $x ) {
    bar $y, $x, $z;
}

Even better! Readable! You don't have to concentrate too hard to see what is going on here.

All this got me thinking, that at this low level of symbols, code readability should be measurable. If punctuation increases the noise and whitespace increases the signal, it should be easy to come up with a formula here. Let's try that, with those examples:

$x=foo();

Tokens you need to understand: 3 ($x, =, and foo). Amount of whitespace: 0. Punctuation: 2 (the parens).

So that might be a SNR of ( 3 + 0 ) / 2 = 1.5.

$x = $foo();

Tokens: 3, whitespace: 2, puctuation: 2. This gives us ( 3 + 2 ) / 2 = 2.5.

And finally:

$x = foo;

which results in a divide by zero exception! In this rare case, this is exactly what we want.

I wonder whether something like this could be turned into a Perl::Critic policy? Or does is already exist?

PS: What I really don't get about "Effective Perl Programming" is the unexplained insistence to put the lexical file handle variable with three-argument open in parentheses. As in open my ($foo), '<', 'foo.bar'.