Perl tooling - less well known but powerful
Tags: perl
Published: 2022-03-05 12:04:53

---
title: Perl tooling - less well known but powerful
published: true
date: 2022-02-24 00:00:00 UTC
tags: perl
canonical_url: http://perl.kiwi/tales/2022/02/24/perl-tooling-less-well-known-but-powerful/
---

Perl is a mature language, businesses have been relying on it for decades, a common refrain is that Perl is battle tested. One of the strengths of a mature language is that the community builds tooling around the language. Perl has some well known tools and some less well known ones. In this tale I want to talk about some of the tooling I like and perhaps are less well known.

Having a good set of tools helps developers build software better and more easily.

## Well known tools

Here are some of the netter known tools that many Perl developers use everyday.

### Perl::Tidy

Consistent formatting is surprisingly important and time consuming. Especially in a team environment running Perl::Tidy is helpful for visually formatting the code so that no matter who writes the changes they are formatted consistently. Be that tabs vs. spaces or aligning the "=" signs in variable assignments.

Perltidy is similar to gofmt (GoLang), prettifier (Node, etc) or elm-format (Elm).

### Perl::Critic

perlcritic is a static analysis tool, it is a very flexible and configurable tool that allows you to define and detect rules on things you don't want in your code base.

For example, a common rule is that all sub routines need an explicit return; perlctitic can enforce this across your code base. There are over 100 "policies" on CPAN for perlcritic. Another one `Perl::Critic::Policy::logicLAB::RequireParamsValidate` insists that the Params::Validate module is used to validate all parameters to your subroutines.

`Perl::Critic::Policy::Variables::ProhibitUnusedVarsStricter` prevents you defining a variable that is never used. This is a pretty common thing to find in a large code base, either because the variable is no longer used or there is a typo somewhere.

### prove

Perl has a strong and well developed testing culture and tooling. `prove` is the test runner most developers are used to using.

There are a wide selection of Test:: modules that you can use for mocking, unit testing, BDD, even enforcing Perl::Critic policies.

### perlbrew

Perlbrew is relatively well known, though perhaps less often used than it might deserve to be.

Perlbrew allows an easy way to install various versions of Perl and switch between them. It is often used on your development machine especially if you need to work on specific versions of Perl so you can support legacy applications. Increasingly we are seeing it used in the building of Docker container.

## Less well known tools

### carton

If you have written any node you will understand carton. With carton you describe your module dependencies in a file called `cpanfile` and then install them with `carton install` This installs all the modules in a `./local` directory and you can then run the perl application with `carton exec` and it runs the code with all the dependencies in the correct path.

This is particularly helpful for when you have multiple projects and they use differing versions of the same dependencies.

Because I use carton with almost all my projects now, I have the following two aliases setup:

`perl='carton exec perl'`

`prove='carton exec prove'`

These mean that if I forget to type `carton exec perl some_script.pl` and type `perl some_script.pl` it works as expected using the local dependencies. The `prove` alias is handy as I almost never remember to type `carti exec prove`.

### update-cpanfile

This command-line tool is really helpful for maintenance of your dependencies. When you run it with `update-cpanfile pin` it will pin your dependencies in the cpanfile. `carton install` will then install the specific versions in the file. This keeps you dependencies consistent; but you could do that by hand in the cpanfile.

Where cpanfile-update is really helpful is when you run it with `update-cpanfile update`, this will make the tool check cpan.org for the latest version of modules and will update the cpanfile for you with the new version.

If you maintain a variety of projects or have lots of dependencies update-cpanfile is a real time saver.

### yath

The simplest way to describe yath is to say that `yath` is the new `prove`... but better.

The venerable prove has been used for a long time, yath is relatively new (2016) and can be used pretty much to do all the things prove does.

However, it's able to do some really interesting things such as running in a daemon mode saving startup times... give it a try.

### perlvars and perlimports

These two tools are super handy for analyzing your code base to ensure that some undesirable code smells.

`perlvars` identifies unused variables in your code.

`perlimports` identifies unused modules you may have included in your code but are not using.

Removing unused variables and modules helps keep your code "tidy" and improve memory consumption and protect against such things as methods from an unused module causing issues when another module has a method with same name for example.

## What am I missing?

This is just a short list of tools I wanted to mention, in part to invite people to let me know what they use.

So if you have some tools you use all the time, drop me an email or a tweet.

Tags: [perl](http://perl.kiwi/tales/tag/perl/)[tools](http://perl.kiwi/tales/tag/tools/)