You can eliminate the warning about unpacking @_ by re-writing as follows:

sub _build_needs_build {
    my ($self, %args) = @_;

    return $self;
}
[download]

Hope that helps,

That was the first thing we did to verify what was being complained about. Yes, that works, but ...

1) we really don't want to replace my $self = shift; in hundreds, if not thousands, of places in our code base.

2) my $self = shift; is what I would consider a very popular idiom that has been in use since (I suspect) many of us first read about OO Perl and how it relates to farm animals. (BTW, where can I find a copy of that very informative original tutorial?)

3) Most importantly, it does nothing to address the following code that allows for rather flexible arg passing (not saying if this is good or bad, just that this concept is pretty standard, too.):

my $self = shift;
my %args = @_ == 1 ? ( period => shift ) : @_;
[download]

I appreciate the response, but unfortunately that has already been viewed as a less-than-optimal resolution.

Per Perl::Critic::Policy::Subroutines::ProhibitUnusedPrivateSubroutines, adding something like this to your .perlcriticrc might suffice:

    [Subroutines::ProhibitUnusedPrivateSubroutines]
    private_name_regex = _(?!build_)\w+
[download]

Thanks! That will help for that, and gives me a few ideas about where else I can look.

Hmm, if I were in your boat I might write something like Perl::Critic::Policy::Moose::BuilderNamingConvention -- ensures proper prefix/sufix for has(...builder...)

But with a better name :)

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

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.

"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

ah, to work on teams ; to work at all :)

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>