Random bits of Perl advice

Learn jargon

To understand documentation, you need to know the jargon that it uses. This jargon is different from other programming languages, so don't think your Java or C knowledge is any help.

Learning the jargon is part of the normal learning process. I recommend Beginning Perl, a free online book written by Simon Cozens.

Here is an incomplete list of things that you will need to understand:

• An object is a reference to a blessed container.
• A list is not the same as an array.
• There are three main contexts: void context, scalar context and list context.
• Things are named or anonymous.
• The language is Perl, the implementation is perl. Never write PERL.
• There are different operators for strings and numbers.
• Some operators perform short circuit logical operations, and these have high and low precedence versions.
• There are lexical variables, package global variables and package global variables that are always in the main namespace.
• Parameters are expected, arguments are passed.
• An operator is either a unary, binary or ternary operator, or a list operator.
• A statement consists of one or more expressions.
• You can use alternative delimiters to avoid the leaning toothpick syndrome.

If there is anything in this list you didn't know already or don't understand, go and find the documentation that explains it.

Keep style consistent

Programming style is a matter of personal preference, but there is one thing that every style should have: consistency. I have described my style, and it's a good idea to describe your own style. That way you make sure you cover important stuff, and it's a handy document to give people who are programming for you.

Write what you mean

Write what you mean, not just something that happens to work. This means you should use scalar @array to get the number of elements in @array, and not $#array + 1, because that would mean the index of the last element of @array plus one.

Avoid high indenting levels

Code blocks and other things should be indented properly, of course, but when you have a maze of nested code blocks, think about writing it differently. Perl has some nice controlled forms of goto that actually make code easier to read. They are redo, last and next. Also, avoid having huge blocks indented. Any given code block larger than 24 lines is hard to read.

For example, this:

for (...) {
    unless (foo) {
        # lots of code here
    } else {
        # some code here
    }
}

can be written as:

for (...) {
    if (foo) {
        # some code here
        next;
    }
    # lots of code here
}

That way, it is immediately clear that nothing else is going to happen. This is also why you write open ... or die $!; instead of:

if (open ...) {
    # entire
    # program
    # here
} else {
    print STDERR $!;
}
__END__

Consider using or next and or last.

Avoid having to clean up

If you get your data clean, you don't have to clean it up. For example, you can read in a file and then remove lines that contain only whitespace, but it's better to just make sure there are no such lines in the first place:

my $file; /\S/ and $file .= $_ while readline $fh;

Most of the time, when you have an s/// with nothing in the RHS (right hand side), that means you're cleaning up because of mistakes you made before. (Or it is user input, and you really wanted to capture what you want instead of remove what you don't want.)

Let Perl help you

When you use strict, Perl forces you to declare variables before you can use them. This means sticking my in front of a variable the first time you use it. That way, Perl knows when you make a typo. This can save you many hours of debugging.

When you use warnings or the -w command line argument, Perl gives additional warnings. This can be unwanted in rare situations, but you can just use no warnings there to temporarily disable them.

When hiring a programmer or buying code, never accept code that doesn't use strict, unless they have a very good reason. That reason should be explained at the place where use strict normally is: the top of the file.

Know where to find help

First stop is documentation. Never ask for help before trying to figure it out on your own. If you ask for help and you get a reference to documentation as the answer, don't whine, but read that documentation.

People have already written answers to your questions. This was done to avoid having to answer the same questions over and over.

The official Perl documentation is available using the perldoc tool. To start reading, type perldoc perl. This will guide you to other documents, like perldoc perlvar, which explains all the special variables.

You can get Perl help at PerlMonks, #perlhelp on EFnet, several usenet groups and many more places.

Oh, and remember that receiving help is a privilege, not a right. It's okay to ask for help, it's not okay to demand help.