Using Perl::Critic to Improve Code

Wade introduced the modules Perl::Critic and Perl::Critic::Bangs. The Perl::Critic module analyzes Perl code with respect to a set of policies looking for violations of defined policies. The default policies are based on the book Perl Best Practices by Damian Conway. The policies in the Perl::Critic::Bangs module were collected by Andy Lester.

One of the best things about the code analysis used by Perl::Critic is the ability to customize the individual policies. The module supports a .perlcriticrc file which allows you to customize both the severity of a policy violation (5 is most severe and 1 is least) and, in some cases, modify the policy itself. In addition, special comment markers can be used to disable a policy for a particular section of code if necessary. This allows you define policies for your environment, while still supporting special purpose overrides for when ugly, power code is needed.

The perlcritic program is used from the command line to test individual files or directories of files. Additionally, the module Test::Perl::Critic supports adding this code critique to your module unit tests.

The obvious questions are

• How well does the module work?
• Will the use of this module improve my code?

First of all, before using the module, you will want to customize the policies to match your coding standards. For example, Wade showed his .perlcriticrc. This includes changes in severity levels for some policies and disabling a few others. This helps avoid false positives from policies that you don't agree with.

Next, run the perlcritic command on some of your code. You may find that you have not followed the policies you thought you had. Wade showed the results when perlcritic was run over two of his projects at various levels of severity. The results were pretty good for his most recent module Device::USB. This module benefits from a recent reading of Perl Best Practices and multiple runs of perlcritic. On the other hand, the module Games::Maze::SVG got extremely bad reports, despite the fact that the same policies had been followed during development.

This shows how important automatic verification can be.

The meeting then moved into a discussion of various policies and best practices. Wade floated the idea of a Houston.pm version of the .perlcriticrc file. Although people expressed some interest, we did not spend much time on it.