Just say "no"

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

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

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

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.

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.


Java developers seem to love CamelCase. Like you I don't find it at all easy to read.

Underscores can look ugly, but they are easier to read than cryptic abbreviations or CamelCase.

For my sins I mostly work in SAP's ABAP language, which has restrictions on the length of variable names, resulting in a lot of cryptic abbreviations (usually in German).

I take it this is your mini-PBP?

Everything you mention is in there - except the last one. And I'm not sure that one isn't! [Well, they recommend "use English" instead of using the lesser-known variables, but at least the English aliases are a lot more readable than the punctuation. "use Esperanto", anybody?]

Not only are these painfully common issues,the weird thing is that they are also painfully obvious! Or is it just us?

Another argument to throw at people here is: keep your sources grepable! Lately I've been seeing that this is good advice and people understand the value of source code in which stuff is easy to find with grep or ack. And, miraculously, if grep is happy, so am I.

There's nothing wrong with using punctuation variables as long as you comment what you're doing. eg ...

local $/; # slurp mode

This gives a less-experienced maintenance programmer the necessary keywords to ask google, without the tiresome overhead of having to write more code or to rely on yet another trivial module.

I love writing and maintaining maintanable code, but code with comments like these that tries to replace my reference manual is usually worse than having no commments at all.

This is the very first occurance of $/ in perldoc perlvar:

local $/; # enable localized slurp mode

It's really not too much to expect from any programmer that they be able to just look that up.

local $/; # perldoc perlvar

Being facetious!

Leave a comment

About Ovid

user-pic Have Perl; Will Travel. Freelance Perl/Testing/Agile consultant. Photo by http://www.circle23.com/. Warning: that site is not safe for work. The photographer is a good friend of mine, though, and it's appropriate to credit his work.