For each new Perl project – and I launch several every week – it is necessary to first prime the working environment. After all, you don't want a pile of spaghetti scripts lying around that nobody can maintain later. A number of template generators are available on CPAN. My attention was recently drawn to App::Skeletor, which uses template modules to adapt to local conditions. Without further ado, I wrote Skeletor::Template::Quick to adapt the original to my needs and uploaded the results to CPAN.

If you store the author info, as shown in Figure 1, in the ~/.skeletor.yml file in your home directory and, after installing the Template module from CPAN, run the skel Foo::Bar command, you can look forward to instantly having a handful of predefined files for a new CPAN distribution dumped into a new directory named Foo-Bar. Other recommended tools for this scaffolding work would be the built-in Perl tool h2xs or the CPAN Module::Starter module.

Figure 1: Skeletor produces the raw skeleton for a new CPAN module.

To help recruit future users of a new module on CPAN as code contributors, the Perl-typical Makefile.PL generated by the tool contains a link to the Github repository with the source code. On the CPAN package repository site, search.cpan.org, the reference is later seen next to the link for downloading the module, and module authors are looking forward to receiving GitHub pull requests for improving the code (Figure 2).

Figure 2: The package page on the CPAN Repository site features a link to the GitHub project hosting the source code under repository.

Solid Foundation

In the newly created code directory, the template generator has created everything you need to get started: from the module files (lib/Foo/Bar.pm) to sample scripts, such as eg/foo-bar and a test suite (t/001Basic.t). Everything is ready for use right from the start. The code files not only contain handy code snippets but also define templates for the documentation. This is important, because documenting how to use scripts and libraries should never be considered a chore.

When I design new code, I first write down how potential users will use my wonders of technology – as far as I can tell in advance. These are mostly object-oriented modules, and before typing the first line of code, I tend to the SYNOPSIS section in the POD area of the source code to describe how the new class is instantiated and what any subsequently invoked methods will do:

my $m = MyModule->new;
$m->dosomething( 42 );

This light exercise often helps me find out whether the imaginary interface really is a smart idea. If it is awkward to handle or feels wrong, the problem is quickly corrected, because still there is no code to rework.

Halt, TDD Police!

When test-driven development (TDD)[1] raised its head about 10 years ago, many folks enthusiastically jumped on the bandwagon. According to its principles, developers first write a test case and then add the new feature. New code was created in pair-programming, and the test case preceding each new feature first failed before being implemented (red bar) or passed when completed (green bar).

This procedure ran out of road a while ago, and many programmers went back to the old routine. I kept two things: I make changes in the code according to the theory of minimum viable product. First, I add the desired function and run tests, and then I use refactoring methods to keep the project clean.

Whenever I find a bug and correct the code, I also try to add a test case, which raises an alarm without the bug fix and runs smoothly after patching. This is priceless to avoid the kind of regressions that inevitably occur when the code becomes more complex or when the project is approaching its tenth release.

In this way, some of my modules sport surprisingly extensive test suites that have built up over the years, simply by following that routine, and at a relatively low cost. Now they're in a state where not even the most diligent of programmers could stomp this out of the ground in reasonable time.

IDE for Old Hands

Opinions differ on development environments. Some prefer a comfortable, mouse-controlled monster tool like Eclipse, which identifies the program syntax and links together all variables and functions so that developers can jump back and forth between definitions and use cases, as well as between files, simply by clicking on code snippets.

When it comes to practical IDEs, I'm not exactly spoiled as an old hand, but I do require lightning fast performance. I use the vim editor with a trick for switching back and forth between a project's files: If you call vim -p File1 File2 [...], vim displays all the files passed in on the command line as tabs, and you can toggle between them with gt (go to tab, right) and gT (left) (Figure 3). To make things even faster, I mapped gt with Vim's map command to Shift+L, and gT to Shift+H (see .vimrc [2]).

Figure 3: Four source files and a test suite open in the Vim editor with tabs.

I can easily remember that a lowercase h moves the cursor to the left in vim, while a lowercase l moves it to the right. So, I move back and forth between the tabs simply by typing the corresponding uppercase letters. If you have many files open at the same time, you can't quit them all at the same time with ZZ or :wq; instead you need to type :qall, or – like I did – map the latter to Shift+Q.