Skip navigation

Tag Archives: policy development

Perl::Critic policies in the DarkPAN.

I’m curious about any people who’ve written custom Perl::Critic policies that aren’t on CPAN.

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?

This post originally appeared at use.perl.org.

Writing configurable Perl::Critic Policies.

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 an instance of Perl::Critic::PolicyConfig (corrected 2009/5/16).
  2. initialize_if_enabled() returns a boolean specifying whether the Policy should be enabled.

This is how the two above policies bow out.

This post originally appeared at use.perl.org.