Adam Kennedy wrote a journal entry where he mentioned "the expense of having to maintain [
## no critic] entries permanently". This inspired the creation of the new policy.
One of the problems with Perl::Critic is that you may, over time, end up with policy disabling comments scattered across your code that no longer apply, making the code harder to understand. This policy will complain about any
## no critic that doesn't actually disable any policies. You then know that you can remove those comments, making your code cleaner and congratulating yourself for solving whatever issue that caused you to put it there in the first place.
What sorts of things are these for?
Have you had a look at Perl::Critic 1.082? Have you read Perl::Critic::DEVELOPER? What do you think?
Generally, Perl::Critic is being used indirectly via a test using Test::P::C or Test::P::C::Progressive, with a
perlcriticrc file that is in the distribution's
The most common reason I have for running
perlcritic is when there's a Test::P::C::Progressive failure. In that case, I'm looking for violations of an individual policy to fix to get the violation count down.
--single-policy overrides all other selection criteria for policies. Its value, like the ones for the
--exclude options, is used as a regex applied against policy names with the
perlcritic --single-policy english
When cleaning up a body of code, I find it easier to fix one kind of problem at a time in a bunch of files, rather than fixing all kinds of problems a single file at a time.
One, this allows initialization to be deferred to the point where we know that the policy is going to be used. P::C::PolicyFactory always instantiates every Policy that it can find. It is up to the P::C::Config object to filter that set down. Primarily, this is an issue for Policies which dynamically load other modules.
Two, this method enables the Policy to decide for itself whether it should be enabled. This means that a Policy that depends upon a module that might not be present can remove itself from the set that violates() gets called on, thus speeding things up because it isn't being called on every PPI::Element.
This originated from Chris Dolan's work on the Perl Foundation grant to create the remaining Policies that can be implemented that enforce one of the ideas in PBP. Specifically, for Documentation::PodSpelling, but this change has been made to all the configurable core Policies. In particular, this helps CodeLayout::RequireTidyCode.
Differences from a constructor other than the obvious first parameter:
This is how the two above policies bow out.
They don't get along.
As of the recent 1.07 release,
Perl::Critic, has started using
Readonly to be more more self-compliant with Perl Best Practices. We had been avoiding use of
constant for the reasons described in the book, but had not been willing to add the
Readonly dependency until now.
Perl::Critic coding standard has been to use sigils for subroutines in
@EXPORT_OK, etc. and import lists, but
Exporter treats them as optional. And, in fact, there's code that strips them off (line 47 in v5.58). I haven't figured out the commonality, but in a few environments, this fails spectacularly. Once we removed the subroutine sigils from everywhere, the problems have gone.
Explicitness: 0, Keyboard laziness: 1.