Perl Style

Style preferences of Larry Wall (creator of Perl)

Essential

• The closing brace of a multi-line BLOCK should line up with the keyword that started the construct.

Helpful

• Use 4-column indents
• Have the opening brace on the same line as the keyword, if possible; otherwise, line it up below the keyword that started the construct
• Add a space before the opening brace of a multi-line BLOCK
• A one-line BLOCK may be put on one line, including braces

• Don't add a space before a semicolon
• Omit the semicolon in a "short" one-line BLOCK

• Add a space around most operators
• Add a space around a "complex" subscript (inside brackets)
• Add blank lines between unrelated sections of code

• Don't add a space between a function name and its opening parenthesis
• Add a space after each comma

• Break long lines after an operator (except and and or)
• Line up corresponding items vertically
• Omit redundant punctuation as long as clarity doesn't suffer
• Add a space after the last parenthesis matching on current line

• Use uncuddled elses

Use the format:

if (expr) {
    statements;
}
else {
    statements;
}

Or, if necessary, the format:

if (expr)
{
    statements;
}
else
{
    statements;
}                       

Rather than the format:

if (expr) {
    statements;
} else {
    statements;
}

The first and second examples line up each elsif and else with the initial if, and allow for easy usage of start-of-line comments before each block.

The second style can be helpful when very long conditional expressions are used, so that, if the expression has to be split up into multiple lines, it's still easy to tell where the expression stops and the block begins.

if (expression && expression && expression
    && expression && expression && expression 
    && expression)
{
    statements;
}

Misc style guidelines

open(FOO,$foo) || die "Can't open $foo: $!";
    # is better than
die "Can't open $foo: $!" unless open(FOO,$foo);
    # because the second way hides the main point of the statement in a modifier.

print "Starting analysis\n" if $verbose;
    # is better than
$verbose && print "Starting analysis\n";
    # because the main point isn't whether the user typed -v or not.

• It's 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
• Module names should begin with a capital letter and use mixed case, but probably without underscores due to limitations in primitive file systems' representations of module names as files that must fit into a few sparse bytes.
• It may be helpful to use letter case to indicate the scope or nature of a variable. For example:

• $ALL_CAPS_HERE - constants only (beware clashes with perl vars!)
• $Some_Caps_Here - package-wide global/static
• $no_caps_here - function scope my() or local() variables

• Function and method names seem to work best as all lowercase: $obj->as_string()
• A leading underscore is sometimes used to indicate that a variable or function should not be used outside the package that defined it
• If you have a really hairy regular expression, use the /x modifier and put in some whitespace to make it look a little less like line noise. Don't use slash as a delimiter when your regexp has slashes or backslashes
• Use the new and and or operators to avoid having to parenthesize list operators so much, and to reduce the incidence of punctuation operators like && and ||
• Call subroutines as if they were functions or list operators to avoid excessive ampersands and parentheses
• Use here documents instead of repeated print() statements (?)
• Line up corresponding things vertically, especially if it'd be too long to fit on one line anyway:

$IDX = $ST_MTIME; 
$IDX = $ST_ATIME   if $opt_u; 
$IDX = $ST_CTIME   if $opt_c; 
$IDX = $ST_SIZE    if $opt_s;

mkdir $tmpdir, 0700 or die "can't mkdir $tmpdir: $!"; 
chdir($tmpdir)      or die "can't chdir $tmpdir: $!"; 
mkdir 'tmp',   0777 or die "can't mkdir $tmpdir/tmp: $!";

Always check the return codes of system calls. Good error messages should go to STDERR, include which program caused the problem, what the failed system call and arguments were, and (VERY IMPORTANT) should contain the standard system error message for what went wrong. Here's a simple but sufficient example:

opendir(D, $dir) or die "can't opendir $dir: $!";

• Line up transliterations when it makes sense:

tr [abc]
   [xyz];

• When possible, aim for variables names with no more than 15 characters
• It's helpful to prototype functions before they're invoked

• Indenting complex boolean expressions

One suggested example:

if ((a and b)
    or (c
       and (d or e)
       and (f or g)))
{
     make_it_so();
}

Another, improvised, example:

if ((a and b)
       or 
    (c and (d or e) and (f or g)))
{
    make_it_so();
}

Reusability

• Generalize the code
• Write a module or object class
• Make the code run cleanly with use strict and use warnings (or -w) in effect