use Perl

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 t/ directory.

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 --include and --exclude options, is used as a regex applied against policy names with the /i, /m, and /x options applied to it. So, for example, if I want to scan for violations of Modules::RequireNoMatchVarsWithUseEnglish in the current directory, I can simply say

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.

As of Perl::Critic 1.07, I would like to discourage the creation of constructors for Policies. Instead, I would encourage the use of P::C::Policy::initialize_if_enabled(). The reasoning is twofold.

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:

1. The configuration is passed in as a hashref and not a hash.
2. initialize_if_enabled() returns a boolean specifying whether the Policy should be enabled.

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.

The 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.