Setting up a Perl development environment

Here are my suggestions on how to set up your Perl development environment:

(NB If you are a Perl novice then start here)

1. Install a copy of Perl
   1. Windows: Strawberry Perl
   2. UNIX developer with a Windows desktop? Use Cygwin
   3. Linux: Your distro should have Perl. See here for some suggestions on installing CPAN modules
   4. UNIX: I built my own and manually installed the modules. Easier than it sounds.
   5. OS/X: Comes with Perl
2. Download a copy of the Perl Documentation and create a convenient shortcut
3. Configure your favourite editor for Perl. There are some guidelines on Perl.net
4. A decent version control tool (I use Git)
5. Install PerlCritic, Perltidy, Devel::REPL, Module::Starter::PBP, GetOpt::Long and RegEx Coach
6. Depending on the work you do consider the following modules as part of your ‘base’ kit:
   1. DBI::SQLite for DB test mocking (NB Depending on your testing needs you will also need other Test modules)
   2. Moose for OO programming
   3. See the list at Perl.Net
7. Run “perl -MModule::Starter::PBP=setup” and accept the defaults
8. Modify the templates used by your editor and Module::Starter so that .pl have the following additional code:

   	# Main program Entry point
   	sub main {
   
   	use Getopt::Long qw(GetOptionsFromArray);
   	# TODO Add options variables here
   	# GetOptionsFromArray(\@_,
   	#TODO Add option processing here
   	#);
   
   	#TODO Add application code here
   	}
   
   	return main(@ARGV)  unless caller();
   	1; # So we can treat this as a module for test purposes
   
   

Use:

• Have the local Perl docs open in your browser — there is a build in search engine
• Test perl assumptions about how Perl will behave by using Regex Coach and re.pl (re.pl runs from a terminal)
• Write your script (and modules) as a set of subroutines that you can test using  Test::More and it’s siblings. You can test script subroutines by writing test scripts in the normal fashion and then running prove with the command line options “-I ./lib -I .“
• Get good with your editor
• Use the branching feature of your version control tool to manage features (you are using Git right?)
• Don’t be afraid to refactor and fix stuff as you discover issues with previously written code

Caveats: This is based on my personal experience and preferences. Use it as a starting point only. I currently use Perl on Cygwin, Solaris and Linux with the Vim or vi editor. I tend to hack data munching scripts and I don’t use OO programming. YMMV.

About these ads