G'day Bod,

Perl::Critic is based on the book Perl Best Practices by Damian Conway (aka TheDamian here at PerlMonks). He is very clear that his book offers a series of guidelines, not hard-and-fast rules. However, as you "wound up the severity", those guidelines and suggestions probably started to look more like rules and regulations.

In my opinion, the practices in the book are generally solid; I probably follow many of them without even thinking. There are some, however, that I don't agree with and, consequently, don't use.

If you look at the Perl::Critic distribution page, you'll see a huge number of Perl::Critic::Policy::* modules; these have explanations of why your (or anyone else's) code was criticised. Here's a quick rundown of the modules relating to the points you raised (I've omitted the Perl::Critic::Policy:: namespace from the link text in each case):

BuiltinFunctions::ProhibitStringyEval

In the main, I follow this policy. The most likely exceptions would be code like 'eval "require $module;";'. I'd question the usage you show. I don't know the context, but in isolation it looks odd:

$ perl -E 'our $V = q{0.1_1}; $V = eval $V; say $V'
0.11
[download]

It seems like extra work to achieve:

$ perl -E 'our $V = q{0.11}; say $V'
0.11
[download]

RegularExpressions::RequireDotMatchAnything

RegularExpressions::RequireExtendedFormatting

RegularExpressions::RequireLineBoundaryMatching

In my opinion, telling people to always use /xms promotes cargo-cult programming. I wonder how many people who use those modifiers actually understand them. None of them makes any sense with your split pattern.

Subroutines::RequireArgUnpacking

I almost always do this. I would have written your code as:

sub new {
    my ($class, %attr) = @_;
    ...
}
[download]

For a rare exception, see "Re: Optional Subroutine Arguments Like in print FILEHANDLE LIST":

sub queue {
    my $Q = ref $_[0] eq 'GLOB' ? shift : \*STDOUT;
    my @list = @_;
    ...
}
[download]

I'd say you have two basic options.

• Run your code through perlcritic. Pick and choose the criticisms you believe to be valid. Possibly modifying your code accordingly.
• Choose to make perlcritic a formal component of your code. Make all changes that it suggests. Avoid criticisms you strongly disagree with using "## no critic" — see "Perl::Critic: BENDING THE RULES".

I see you're using http://perlcritic.com/; I'm not familiar with that URL. See also: perlcritic (for on-the-fly, command line critique) and Test::Perl::Critic (to integrate with your test suite).

In addition to "Perl Best Practices" (2005 book) you may be interested in "Modern Perl Best Practices" (2014 video course) also by Damian Conway. I own a copy of the former and have read it a few times; I've only seen a trailer for the latter work.

Finally, I've voiced my opinions here; I'm well aware that others have differing opinions. Listen to all for a spread of advice then make your own mind up. :-)