Ovid

Beyond obvious problems with not using strict and warnings, here are some of my personal pet peeves regarding common Perl bad practices.

• Stop using indirect object notation

We already know it leads to subtle bugs. Why keep doing this?

my $foo = new Foo('baz'); # bad!

• DontUseCamelCase except for package names.

You want people to be able to read your code.

$foo = $DontUseCamelCase;
$foo = $do_use_underscores;

From "perlstyle":

While short identifiers like $gotit are probably ok, use underscores to separate words in longer identifiers. It is generally easier to read $var_names_like_this than $VarNamesLikeThis, especially for non-native speakers of English. It's also a simple rule that works consistently with VAR_NAMES_LIKE_THIS.

I could be mistaken, but I believe CamelCase was largely a holdover from Smalltalk which only allowed a leading letter and then optional letters and digits. TheReadabilityOfPerlIsBadEnoughWithoutCamelCase.

• Don't use Perl's lesser-known built-in variables unless you document them.

Just because you instantly know what $[, $*, and $; do doesn't mean others do. You're just making life harder for others unecessarily.

if (@errors) {
    local $" = ', ';
    croak("Embezzlement failed: @errors");
}

I have a bad habit of doing that. I have to stop that because it's not fair to maintenance programmers.

• Limit your lines of code to a reasonable number of characters.

I've seen CPAN modules where the lines of code force horizontal scrollbars in my browser, not just wrapping issues in my editor. Sure, I can resize my editor and I don't have to worry about old-fashioned 80 colomn terminal limitations. I haven't seen that in over a decade.

The real problem here is complexity: if you have a line of code which is 300 characters long, something's wrong. Even if it's a simple variable assignment, that implies you have a huge constant in your code. Why? And why make lives miserable for other people who simply don't want to carefully read through all of that to make sure there's a mistake? Keep your lines of code short and easy to read. Don't do too much.

• Stop being an @$$.

OK, this isn't about code, but it's still a common problem. Just because you're upset with someone or feeling superior doesn't give you a right to call them a f***wit. Maybe you're impressed with yourself or just can't contain your anger, but there's really no place for it in adult conversation. Hopefully you'll outgrow it and leave that to the **** programmers.