Everyones a (Perl) critic, and you can be too!

The perlcritic tool is often your first defense against awkward, hard to read, error-prone, or unconventional constructs in your code, per its description. Its part of a class of programs historically known as linters, so-called because like a clothes dryer machines lint trap, they detect small errors with big effects. (Another such linter is perltidy, which Ive referenced in the past.)

You can use perlcritic at the command line, integrated with your editor, as a git pre-commit hook, or (my preference) as part of your author tests. Its driven by policies, individual modules that check your code against a particular recommendation, many of them from Damian Conways Perl Best Practices (2005). Those policies, in turn, are enabled by PPI, a library that transforms Perl code into documents that can be programmatically examined and manipulated much like the Document Object Model (DOM) is used to programmatically access web pages.

perlcritic enables the following policies by default unless you customize its configuration or install more. These are just the gentle (severity level 5) policies, so consider them the bare minimum in detecting bad practices. The full set of included policies goes much deeper, ratcheting up the severity to stern, harsh, cruel, and brutal. Theyre further organized according to themes so that you might selectively review your code against issues like security, maintenance, complexity, and bug prevention.

• BuiltinFunctions::ProhibitStringyEval
• BuiltinFunctions::RequireGlobFunction
• ClassHierarchies::ProhibitOneArgBless
• ControlStructures::ProhibitMutatingListFunctions
• InputOutput::ProhibitBarewordFileHandles
• InputOutput::ProhibitInteractiveTest
• InputOutput::ProhibitTwoArgOpen
• InputOutput::RequireEncodingWithUTF8Layer
• Modules::ProhibitEvilModules
• Modules::RequireBarewordIncludes
• Modules::RequireFilenameMatchesPackage
• Subroutines::ProhibitExplicitReturnUndef
• Subroutines::ProhibitNestedSubs
• Subroutines::ProhibitReturnSort
• Subroutines::ProhibitSubroutinePrototypes
• TestingAndDebugging::ProhibitNoStrict
• TestingAndDebugging::RequireUseStrict
• ValuesAndExpressions::ProhibitLeadingZeros
• Variables::ProhibitConditionalDeclarations
• Variables::RequireLexicalLoopIterators

My favorite above is probably ProhibitEvilModules. Aside from the colorful name, a development team can use it to steer people towards an organizations favored solutions rather than deprecated, buggy, unsupported, or insecure ones. By default, it prohibits Class::ISA, Pod::Plainer, Shell, and Switch, but you should curate and configure a list within your team.

Speaking of working within a team, although perlcritic is meant to be a vital tool to ensure good practices, its no substitute for manual peer code review. Those reviews can lead to the creation or adoption of new automated policies to save time and settle arguments, but such work should be done collaboratively after achieving some kind of consensus. This is true whether youre a team of employees working on proprietary software or a group of volunteers developing open source.

Of course, reasonable people can and do disagree over any of the included policies, but as a reasonable person, you should have good reasons to disagree before you either configure perlcritic appropriately or selectively and knowingly bend the rules where required. Other CPAN authors have even provided their own additions to perlcritic, so its worth searching CPAN under Perl::Critic::Policy:: for more examples. In particular, these community-inspired policies group a number of recommendations from Perl developers on Internet Relay Chat (IRC).

Personally, although I adhere to my employers standardized configuration when testing and reviewing code, I like to run perlcritic on the brutal setting before committing my own. What do you prefer? Let me know in the comments below.

Cover image: Everyones a critic graifitti under Mancunian Way in Manchester by Alex Pepperhill is licensed under CC BY-ND 2.0