Perl::Critic: Life after Moose?

2019-03-24 07:02发布

问题:

I've started a conversion of a project to Moose and the first thing I noticed was that my critic/tidy tests go to hell. Moose, Tidy and Critic don't seem to like each other as much as they used to.

Are there docs anywhere on how to make critic/tidy be more appreciative of the Moose dialect? What do most Moose users do? Relax/ditch critic for the more heavy Moose modules? Custom policies?

回答1:

Have you seen Perl::Critic::Moose?



回答2:

Both of them can be configured into detail.

I have no idea why perltidy wouldn't like it, it has nothing to do with it. Perltidy only governs style. You can change the style of your code without changing any functionality, it's mostly a matter of whitespace really. You should either change your style or change the perltidy configuration using the .perltidyrc file.

I don't know what problems perlcritic has with it (lvalue methods perhaps?), but you could consider turning off those specific policies using the .perlcriticrc file. Also, if your perlcritic is old you may want to upgrade it, as some old versions gave some incorrect errors in Moose classes.



回答3:

Earlier versions of Perl::Critic's "use strict" policy wasn't aware of Moose enabling strict for you, but that'll be fixed if you upgrade Perl::Critic.

I use both Perl::Critic and Perl::Tidy with Moose, and I don't see anything particularly broken. Well, actually, I can't get Perl::Tidy to layout things like this properly:

my $apple = Apple->new({
    color => "red",
    type  => "delicious",
});

Tidy will insist that ( and { are two opening levels of indentation, and it will just look this silly:

my $apple = Apple->new({
        color => "red",
        type  => "delicious",
});

But we had this problem before; the coding convention in the project is to use a hashref, not a hash, for named parameters. So it's not really a Moose related problem as such.

What exactly are your symptoms?

/J



回答4:

I have no problem with Critic tests - admittedly I run at severity=3, at least in part because some of what I have to work with is legacy code that I don't have /time/ to tidy, but my Moose stuff sails through that.