Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

elliot (8136)

  (email not shown publicly)
AOL IM: elliotshank (Add Buddy, Send Message)

Journal of elliot (8136)

Thursday January 01, 2009
04:01 PM

The most significant Perl::Critic release in a long while.

Perl::Critic 1.094 is on its way to a CPAN mirror near you. There are a number of changes in it, but there's one in particular that I want to point out. A new policy called Miscellanea::ProhibitUselessNoCritic.

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.

Thursday May 15, 2008
01:01 PM

Things I like.

Monday May 05, 2008
02:05 PM

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?

Tuesday April 29, 2008
06:04 PM

This is my Perl blog...

... there are many others like it, but this one is mine.
Sunday March 23, 2008
11:32 AM

The single most useful perlcritic command-line option.

For me, it's --single-policy.

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.

Sunday September 16, 2007
08:55 PM

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.
  2. initialize_if_enabled() returns a boolean specifying whether the Policy should be enabled.

This is how the two above policies bow out.

Friday September 07, 2007
05:04 PM

Lesson of the day: Readonly, Exporter, and subroutine sigils

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.