in reply to perlcritic and OO Perl (including Moose) idioms

Can anyone point me in the right direction to deal with what I think is undesirable behavior by perlcritic?

Stop using perlcritic as if its alive, its dead. perlcritic is dumb, it can't make choices for you, you have to read the docs and make your choices, and update your configuration

Read https://metacpan.org/module/Perl::Critic::Policy::Subroutines::ProhibitUnusedPrivateSubroutines, update your critic configuration file, the end :)

See also Perl::Critic::Moose for extra criticisms to install/configure/complainabout :)

You might try finding an existing "perlcriticrc for moose" , not unlike Perl::Critic::Dynamic::Moose

If I used perlcritic or moose more I might know more about this, but currently I'm satisfied with mentally ignoring any rules that don't make sense for me on the rare occasion I use perlcritic

  • Comment on Re: perlcritic and OO Perl (including Moose) idioms (perlcritic is dead/dumb, perlcriticrc for moose)

Replies are listed 'Best First'.
Re^2: perlcritic and OO Perl (including Moose) idioms
by boftx (Deacon) on Sep 20, 2013 at 03:17 UTC

    If I were in a position to establish the rules I would not bother with perlcritic but instead rely much more heavily on code reviews. But ...

    Unfortunately, much of this will be a team decision, and I already know that the team is going to want to use perlcritic simply because it will automate some things (yeah, right.) In the meantime, I am looking for tips such as what documentation I really need to look at, and how others have addressed what I think are common problems.

    Thanks for the response, it was helpful.

    Update: changed title back to what I had originally.

[reply]
      "Unfortunately, much of this will be a team decision, and I already know that the team is going to want to use perlcritic simply because it will automate some things (yeah, right.) In the meantime, I am looking for tips such as what documentation I really need to look at, and how others have addressed what I think are common problems."

      I'd suggest that you get your team to read the first section of the Preface to "Perl Best Practices" and note how many times the words "guidelines" and "suggestions" are used. Ensure they've read the the first sentence of the third paragraph: "This book doesn't doesn't try to offer the one true universal and unequivocal set of best practices.". Show them the publishing date (2005) and make certain they understand this is eight years old.

      All too often I've come across statements like "We've got to code it that way because PBP says so." Your team really do need to understand that these are guidelines and suggestions, not rules and regulations. I think once you get that message across, you'll have a much easier time of getting a concensus on a configuration which is useful in that it identifies code which could be improved, as opposed to one that blindly follows every PBP dot-point.

      Just so you know, I like a fair bit of the advice in PBP: parts I follow, other parts I don't. I didn't want this to come across as a PBP bashing exercise on my part. :-)

      -- Ken

[reply]
      ah, to work on teams ; to work at all :)
[reply]

      Turns out there is now such a thing

      Perl::Critic::Freenode - A set of Perl::Critic policies to enforce the practices generally recommended by the denizens of #perl on Freenode IRC. Because this policy "theme" is designed to be used with zero configuration on the command line, some duplication will occur if it is used in combination with core Perl::Critic policies.

      perlcritic --theme freenode script.pl

      2018-10-21 Athanasius changed <h1> tags to <h3>

[reply]

In Section Seekers of Perl Wisdom