Perl Development

Posted by Joe Topjian on August 2, 2010 under Development | Be the First to Comment

Introduction

After finishing my Python Development article, I was curious as to how I could create a better Perl development environment for myself.

Why Perl? I first learned Perl in 1997 when I was a Sophomore in High School. It has stuck ever since. No matter what other language I learn or focus on, I’m always able to crank out a semi-decent Perl script faster. Emphasis on semi-decent. I wanted to change that to almost-decent, so I started researching Perl testing, proper distribution development, and general Perl development tricks.

Table of Contents

• Development Environment
  • Prerequisites
  • Development Environment
• Actual Developing
  • POD Documentation
• Resources
• Conclusion

Development Environment

Prerequisites

To begin developing — or even just toying around — I create a new Perl Virtual Environment. Once the environment is set up, I have a few standard modules I install (note: some of these modules listed might be installed as prerequisites for other modules in the list):

• Module::Starter
• Module::Build
• Test::Harness
• Perl::Tidy
• Pod::Coverage

More will be installed depending on the project, but these are usually standard.

Development Environment

Rather than using a fancy Eclipse install with several plug-ins, my Perl development environment consists of the command line programs vim, hg, prove, and perltidy. I have a few keyboard shortcuts for vim:

" Tidy entire file:
nnoremap <silent> _t :%!perltidy -q<Enter> 

" Support Perl testing
nnoremap _T <Esc>:!prove -vl %<Enter>

" Check syntax
nnoremap _s <Esc>:!perl -c %<Enter> 

" Quick comment
nmap # I# ^[j

" Perl templates
nnoremap ,perl <Esc>I#!/usr/bin/env perl<Enter>use strict;<Enter>use warnings;
<Enter><Enter><Esc>I

I am definitely not the most experienced vim user, but these shortcuts work well for me.

The last shortcut is worth some discussion. In vim, when I type in ,perl, I get the following result:

    #!/usr/bin/env perl
    use strict;
    use warnings;

Almost every article about how to write better Perl programs will always mention the strict and warnings pragma. With good reason, too — these pragmas will not only force you to write more mature code, but they will also help you find errors in your code immediately. If you take anything away from this article, it would be to please begin writing Perl scripts with these two pragmas — it’ll do a world of help.

Actual Developing

If I’m creating just a simple Perl script, then I just jump right into vim and start typing away. To test, I just save the file and run the script. Wash, rinse, repeat. Bad habit, yes, I know.

However, if I’m developing a more serious module, either for personal or CPAN purposes, I’m much more strict.

I begin by using module-starter to create a directory structure:

$ module-starter --module=My::Module --author="Joe Topjian" --email=joe@terrarum.net --builder=Module::Build

Next, I flesh out some quick code in the My-Module/lib/My/Module.pm file and then some quick tests in My-Module/t/module.t file.

In my shell, my cwd is My-Module. When writing tests, the relative path for the test file is t/module.t. I’m able to just type _T in vim and prove will execute all tests correctly.

POD Documentation

While I prefer Python’s style of in-code documentation better, Perl’s isn’t so bad. module-starter does a great job at creating a base Module.pm file that includes sample blocks of documentation to edit and quickly get started with documenting your module.

Once I’m finished with the module, I’ll run either pod2html or pod2text to convert the in-code documentation to the Module’s README file.

Packaging the Module

When the Module is done and all tests are passing, I add all necessary dependency modules to the Build.PL file. I then run:

$ perl Build.PL
$ ./Build dist

If a resulting My-Module-0.01.tar.gz is successfully created, I then switch to a new, clean Perl Virtual Environment and test installing it. If all tests still pass and CPAN is able to resolve all dependencies, then I’m pretty confident the module is stable and good enough for production use. If I plan on uploading the module to CPAN (I have only uploaded one module and that was just recently), then I do that during this phase.

Resources

Unfortunately there is not one single definitive guide or book that has helped me learn proper Perl development. The good news is that there are several resources that I have collectively learned from and, all in all, have allowed me to avoid making any guesses as to a proper way.

• Modern Perl: The Book: The Draft: This is a recent, rough publication from chromatic.
• Perl Hacks
• Effective Perl Programming
• Perl Testing: A Developer’s Notebook

With the exception of the first book (which is available for free), all of these books are available on Safari. Although the monthly cost for Safari is rather steep, I find it well worth the money.

Conclusion

This article was not as detailed as my Python Development article, nor did I describe a real project walk-through. Even so, I hope this information provides some use to other people curious about creating a more organized and professional development environment for Perl.