Everyone’s a (Perl) critic, and you can be too!
Tags: perl, perlcritic, cpan, lint
Published: 2021-09-21 15:16:16

---
title: Everyone’s a (Perl) critic, and you can be too!
published: true
date: 2021-09-21 14:00:00 UTC
tags: Perl,perlcritic,CPAN,lint
canonical_url: https://phoenixtrap.com/2021/09/21/everyones-a-perl-critic/
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gk8n5t2s38e4r35ufei2.jpg
---

The [`perlcritic`](http://perlcritic.com/) tool is often your first defense against “awkward, hard to read, error-prone, or unconventional constructs in your code,” per its [description](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic#DESCRIPTION). It’s part of a class of programs historically known as [linters](https://en.wikipedia.org/wiki/Lint_(software)), so-called because like a clothes dryer machine’s lint trap, they “detect small errors with big effects.” (Another such linter is [`perltidy`](http://perltidy.sourceforge.net/), which I’ve [referenced](https://phoenixtrap.com/tag/perltidy/) in the past.)

You can use `perlcritic` [at the command line](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic), [integrated with your editor](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic#EDITOR-INTEGRATION), as a [`git` pre-commit hook](https://git-scm.com/docs/githooks#_pre_commit), or (my preference) as [part of your author tests](https://metacpan.org/pod/Test::Perl::Critic). It’s driven by [policies](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic#THE-POLICIES), individual modules that check your code against a particular recommendation, many of them from [Damian Conway’s _Perl Best Practices_](https://www.oreilly.com/library/view/perl-best-practices/0596001738/) (2005). Those policies, in turn, are enabled by [PPI](https://metacpan.org/pod/PPI), a library that transforms Perl code into documents that can be programmatically examined and manipulated much like the [Document Object Model (DOM)](https://en.wikipedia.org/wiki/Document_Object_Model) is used to programmatically access web pages.

`perlcritic` enables the following policies by default unless you [customize its configuration](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic#CONFIGURATION) or install more. These are just the “gentle” ([severity](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic#-severity-N) level 5) policies, so consider them the bare minimum in detecting bad practices. The [full set of included policies](https://metacpan.org/dist/Perl-Critic/view/lib/Perl/Critic/PolicySummary.pod) goes much deeper, ratcheting up the severity to “stern,” “harsh,” “cruel,” and “brutal.” They’re further organized according to [themes](https://metacpan.org/pod/Perl::Critic#POLICY-THEMES) so that you might selectively review your code against issues like security, maintenance, complexity, and bug prevention.

- [BuiltinFunctions::ProhibitSleepViaSelect](https://metacpan.org/pod/Perl::Critic::Policy::BuiltinFunctions::ProhibitSleepViaSelect)
- [BuiltinFunctions::ProhibitStringyEval](https://metacpan.org/pod/Perl::Critic::Policy::BuiltinFunctions::ProhibitStringyEval)
- [BuiltinFunctions::RequireGlobFunction](https://metacpan.org/pod/Perl::Critic::Policy::BuiltinFunctions::RequireGlobFunction)
- [ClassHierarchies::ProhibitOneArgBless](https://metacpan.org/pod/Perl::Critic::Policy::ClassHierarchies::ProhibitOneArgBless)
- [ControlStructures::ProhibitMutatingListFunctions](https://metacpan.org/pod/Perl::Critic::Policy::ControlStructures::ProhibitMutatingListFunctions)
- [InputOutput::ProhibitBarewordFileHandles](https://metacpan.org/pod/Perl::Critic::Policy::InputOutput::ProhibitBarewordFileHandles)
- [InputOutput::ProhibitInteractiveTest](https://metacpan.org/pod/Perl::Critic::Policy::InputOutput::ProhibitInteractiveTest)
- [InputOutput::ProhibitTwoArgOpen](https://metacpan.org/pod/Perl::Critic::Policy::InputOutput::ProhibitTwoArgOpen)
- [InputOutput::RequireEncodingWithUTF8Layer](https://metacpan.org/pod/Perl::Critic::Policy::InputOutput::RequireEncodingWithUTF8Layer)
- [Modules::ProhibitEvilModules](https://metacpan.org/pod/Perl::Critic::Policy::Modules::ProhibitEvilModules)
- [Modules::RequireBarewordIncludes](https://metacpan.org/pod/Perl::Critic::Policy::Modules::RequireBarewordIncludes)
- [Modules::RequireFilenameMatchesPackage](https://metacpan.org/pod/Perl::Critic::Policy::Modules::RequireFilenameMatchesPackage)
- [Subroutines::ProhibitExplicitReturnUndef](https://metacpan.org/pod/Perl::Critic::Policy::Subroutines::ProhibitExplicitReturnUndef)
- [Subroutines::ProhibitNestedSubs](https://metacpan.org/pod/Perl::Critic::Policy::Subroutines::ProhibitNestedSubs)
- [Subroutines::ProhibitReturnSort](https://metacpan.org/pod/Perl::Critic::Policy::Subroutines::ProhibitReturnSort)
- [Subroutines::ProhibitSubroutinePrototypes](https://metacpan.org/pod/Perl::Critic::Policy::Subroutines::ProhibitSubroutinePrototypes)
- [TestingAndDebugging::ProhibitNoStrict](https://metacpan.org/pod/Perl::Critic::Policy::TestingAndDebugging::ProhibitNoStrict)
- [TestingAndDebugging::RequireUseStrict](https://metacpan.org/pod/Perl::Critic::Policy::TestingAndDebugging::RequireUseStrict)
- [ValuesAndExpressions::ProhibitLeadingZeros](https://metacpan.org/pod/Perl::Critic::Policy::ValuesAndExpressions::ProhibitLeadingZeros)
- [Variables::ProhibitConditionalDeclarations](https://metacpan.org/pod/Perl::Critic::Policy::Variables::ProhibitConditionalDeclarations)
- [Variables::RequireLexicalLoopIterators](https://metacpan.org/pod/Perl::Critic::Policy::Variables::RequireLexicalLoopIterators)

My favorite above is probably [ProhibitEvilModules](https://metacpan.org/pod/Perl::Critic::Policy::Modules::ProhibitEvilModules). Aside from the colorful name, a development team can use it to steer people towards an organization’s favored solutions rather than “deprecated, buggy, unsupported, or insecure” ones. By default, it prohibits [Class::ISA](https://metacpan.org/pod/Class::ISA), [Pod::Plainer](https://metacpan.org/pod/Pod::Plainer), [Shell](https://metacpan.org/pod/Shell), and [Switch](https://metacpan.org/pod/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, it’s no substitute for manual [peer code review](https://en.wikipedia.org/wiki/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 you’re 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](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic#BENDING-THE-RULES) where required. Other CPAN authors have even provided their own additions to `perlcritic`, so it’s worth [searching CPAN under “Perl::Critic::Policy::”](https://metacpan.org/search?q=Perl%3A%3ACritic%3A%3APolicy%3A%3A) for more examples. In particular, [these community-inspired policies](https://metacpan.org/pod/Perl::Critic::Community) group a number of recommendations from [Perl developers on Internet Relay Chat (IRC)](https://perldoc.perl.org/perlcommunity#IRC).

Personally, although I adhere to my employer’s 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: [“Everyone’s a critic — graifitti under Mancunian Way in Manchester”](https://www.flickr.com/photos/56278705@N05/7859287174) by [Alex Pepperhill](https://www.flickr.com/photos/56278705@N05) is licensed under [CC BY-ND 2.0](https://creativecommons.org/licenses/by-nd/2.0/?ref=ccsearch&atype=rich)_