The Funhouse Mirror of Perl Criticism
Tags: perl, bestpractices, oop, signatures
Published: 2021-07-27 14:19:02

---
title: The Funhouse Mirror of Perl Criticism
published: true
date: 2021-07-27 14:00:00 UTC
tags: Perl,bestpractices,OOP,signatures
canonical_url: https://phoenixtrap.com/2021/07/27/the-funhouse-mirror-of-perl-criticism/
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1zbe2f846n85i4ldn65l.jpeg
---

[Last week’s article](https://phoenixtrap.com/2021/07/20/the-four-noisy-horsemen-of-perl-hate/) got a [great response on Hacker News](https://news.ycombinator.com/item?id=27902296), and this particular comment caught my eye:

> I think this is the real point about Perl code readability: it gives you enough flexibility to do things however you like, and as a result many programmers are faced with a mirror that reflects their own bad practices back at them.
> 
> [_orev, Hacker News_](https://news.ycombinator.com/item?id=27905212)

This is why [Damian Conway’s _Perl Best Practices_](https://www.oreilly.com/library/view/perl-best-practices/0596001738/) (2005) is one of my favorite books and [`perlcritic`](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic), the code analyzer is one of my favorite tools. (Though the former could do with an update and the latter includes policies that contradict Conway.) Point `perlcritic` at your code, maybe add some [other policies](https://metacpan.org/search?q=Perl%3A%3ACritic%3A%3APolicy) that agree with your house style, and gradually ratchet up the [severity level](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic#-severity-NAME) from “gentle” to “brutal.” **All kinds of bad _juju_ will come to light** , from [wastefully using `grep`](https://metacpan.org/pod/Perl::Critic::Policy::BuiltinFunctions::ProhibitBooleanGrep) to having [too many subroutine arguments](https://metacpan.org/pod/Perl::Critic::Policy::Subroutines::ProhibitManyArgs) to catching [private variable use from other packages](https://metacpan.org/pod/Perl::Critic::Policy::Variables::ProtectPrivateVars). `perlcritic` offers a useful baseline of conduct and you can always customize [its configuration](https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic#CONFIGURATION) to your own tastes.

The other conformance tool in a Perl developer’s belt is [`perltidy`](https://metacpan.org/dist/Perl-Tidy/view/bin/perltidy), and it too has a [Conway-compatible configuration](https://metacpan.org/dist/Perl-Tidy/view/bin/perltidy#-pbp,-perl-best-practices) as well as its default [Perl Style Guide](https://perldoc.perl.org/perlstyle) settings. I’ve found that more than anything else, **`perltidy` helps settle arguments** both between developers and between their code in helping to avoid excessive merge conflicts.

But apart from extra tools, Perl the language itself can be bent and even broken to suit just about anyone’s agenda. Those used to more [bondage-and-discipline languages](http://catb.org/jargon/html/B/bondage-and-discipline-language.html) _(hi, Java!)_ might feel revulsion at the lengths to which this has sometimes been taken, but per the quote above this is **less an indictment of the language and more of its less methodical programmers**.

Some of this behavior can be rehabilitated with `perlcritic` and `perltidy`, but what about other sins attributed to Perl? Here are a few perennial “favorites”:

## Objects and Object-Oriented Programming

Perl has a [minimalist object system](https://perldoc.perl.org/perlobj) based on earlier-available language concepts like [data structures](https://perldoc.perl.org/perlobj#An-Object-is-Simply-a-Data-Structure) (often hashes, which it [has in common with JavaScript](https://www.quirksmode.org/js/associative.html)), [packages](https://perldoc.perl.org/perlobj#A-Class-is-Simply-a-Package), and [subroutines](https://perldoc.perl.org/perlobj#A-Method-is-Simply-a-Subroutine). Since Perl 5’s release in 1994 much verbose OO code has been written using these tools.

The good news is that since 2007 we’ve had a sophisticated metaobject-protocol-based layer on top of them called [Moose](https://metacpan.org/pod/Moose), since 2010 a lightweight but forward-compatible system called [Moo](https://metacpan.org/pod/Moo), and a couple of even tinier options [as described in the Perl OO Tutorial](https://perldoc.perl.org/perlootut#OO-System-Summary). Waiting in the wings is [Corinna](https://github.com/Ovid/Cor/wiki), an effort to bring next-generation object capabilities into the Perl core itself, and [Object::Pad](https://metacpan.org/pod/Object::Pad), a testbed for some of the ideas in Corinna that you can use today in current code. (Really, please try it—the author [needs feedback](https://twitter.com/cpan_pevans/status/1415596477968261121)!)

All this is to say that **99% of the time you never need trouble yourself** with [`bless`](https://perldoc.perl.org/functions/bless), constructors, or writing accessors for class or object attributes. Smarter people than me have done the work for you, and you might even find a concept or three that you wish other languages had.

## [Contexts](https://perldoc.perl.org/perldata#Context)

There are two major ones: list and scalar. Another way to think of it is “plural” vs. “singular” in **English, which is hopefully a thing you’re familiar with** as you’re reading this blog.

Some functions in Perl act differently depending on whether the expected return value is a list or a scalar, and a function will provide a list or scalar context to its arguments. Mostly these act just as you would expect or would like them to, and you can find out how a function behaves by [reading its documentation](https://perldoc.perl.org/perlfunc). Your own functions can [behave like this too](https://perldoc.perl.org/functions/wantarray), but there’s usually no need as “both scalars and lists are automatically interpreted into lists.” Again, Perl’s [DWIMmery](https://perldoc.perl.org/perlglossary#dwimmer) at work.

## Subroutine and Method Arguments

I’ve [already written about this](https://phoenixtrap.com/2021/01/27/better-perl-with-subroutine-signatures-and-type-validation/). [Twice](https://phoenixtrap.com/2021/02/16/better-perl-more-on-signatures-and-types/). And [presented](https://phoenixtrap.com/2021/02/11/slides-from-tonights-houston-perl-mongers-presentation/) about it. [Twice](https://phoenixtrap.com/2021/03/03/tuesday-at-boston-pm-perl-subroutine-signatures-and-type-validation/). The short version: Perl has [signatures](https://perldoc.perl.org/perlsub#Signatures), but they’ve been considered experimental for a while. In the meantime, there are alternatives on [CPAN](https://www.cpan.org/). You can even have type constraints if you want.

* * *

I’ll leave you with this: Over the past month, [Neil Bowers](http://neilb.org/) of the [Perl Steering Council](https://perldoc.perl.org/perlgov#The-Steering-Council) has been collecting [quirks](https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260705.html) like these from Perl developers. [The PSC is reviewing](https://www.nntp.perl.org/group/perl.perl5.porters/2021/07/msg260915.html) this collection for potential documentation fixes, bug fixes, further discussion, etc. I wouldn’t expect to see any fundamental changes to the language out of this effort, but it’s a good sign that potentially confusing features are being addressed.