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

It seems like extra work to achieve:

$ perl -E 'our $V = q{0.11}; say $V' 0.11
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) = @_; ... }

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 = @_; ... }

I'd say you have two basic options.

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. :-)

— Ken


In reply to Re: How Critical is Critic? by kcott
in thread How Critical is Critic? by Bod

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.