Perl Tips

Starting a module with Module::Starter

2008-10-15T00:00:00Z

Starting a new module can be a lot of work. A good module should have a build system, documentation, a test suite, and numerous other bits and pieces to assist in its easy packaging and development. These are useful even if we never release our module to CPAN.

Setting this up can be a lot of work, especially if you've never done it before. While the h2xs tool that comes with Perl will do some of this for you, it's showing its age, and doesn't allow us to take advantage of recent tools. We want to spend our time writing code, not trying to decode our build system.

That's where Module::Starter comes in handy. It provides a simple, command-line tool to create a skeleton module quickly and easily.

Read more...

autodie - The art of Klingon Programming

2008-08-20T00:00:00Z

   bIlujDI' yIchegh()Qo'; yIHegh()!

   It is better to die() than to return() in failure.

       -- Klingon programming proverb.

The problem with error handling

One of the first things most people learn when programming in Perl is to always check to see if system calls like open are successful. The most common construct seen for such checking is the do or die style:

    open(my $fh, '<', $filename) or die "Can't open $filename - $!";

The problem with do or die is that for calls to built-ins like open, it's very rare that we'd want to do anything other than die on failure. Even if we wish to handle the error, the call to die provides a convenient way to generate an exception, which we can then trap using an eval block.

Unfortunately, the do or die construct is tiresome to repeat, easily forgotten, and in many cases takes up more code and visual space than the function it is designed to guard.

Wouldn't it be nice if functions could die automatically on failure?

Read more...

Improving regular expressions

2008-06-06T00:00:00Z

Many programmers find regular expressions to be esoteric constructions. They're dense, complex, and for many people utterly incomprehensible. Large regular expressions without sufficient documentation can be staggeringly difficult to maintain, so it's no surprise that many developers are happy if they match at all, even if they're not as fast or maintainable as they could be.

This tip will focus on how to make regular expressions easier to understand, easier to maintain, and faster to run.

Read more...

Building executables with PAR

2008-05-23T00:00:00Z

One of Perl's greatest strengths is the huge number of modules available on the CPAN. Many really tricky problems can be made quite simple with just the use of a few appropriate modules.

Unfortunately, using CPAN modules results in another problem. Using modules makes development easier, but it makes installing code much more difficult. Not only do we have to ensure that the modules we use are installed, but we also need to ensure they modules they depend upon also get installed. Worst of all, we may be writing code for machines that don't even have Perl installed at all, or a version so old that none of our modules work on it.

If this seems familiar, then PAR, the Perl Archiver, may provide relief from your installation woes. PAR allows you to bundle all of your modules, configuration files, and other dependencies into a single compressed archive, and then distribute that along with, or instead of, your code.

Read more...

Smart-match

2008-04-18T00:00:00Z

Perl 5.10 introduces a new-operator, called smart-match, written ~~. As the name suggests, smart-match tries to compare its arguments in an intelligent fashion. Using smart-match effectively allows many complex operations to be reduces to very simple statements.

Unlike many of the other features introduced in Perl 5.10, there's no need to use the feature pragma to enable smart-match, as long as you're using 5.10 it's available.

The smart-match operator is always commutative. That means that $x ~~ $y works the same way as $y ~~ $x. You'll never have to remember which order to place to your operands with smart-match.

Read more...