elliot's Journal http://use.perl.org/~elliot/journal/ elliot's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:44:24+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 elliot's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~elliot/journal/ The most significant Perl::Critic release in a long while. http://use.perl.org/~elliot/journal/38199?from=rss <a href="http://search.cpan.org/dist/Perl-Critic/">Perl::Critic</a> 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. <p> Adam Kennedy wrote <a href="http://use.perl.org/article.pl?sid=08/09/24/1957256">a journal entry</a> where he mentioned "the expense of having to maintain [<code>## no critic</code>] entries permanently". This inspired the creation of the new policy. </p><p> 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 <code>## no critic</code> 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.</p> elliot 2009-01-01T21:01:34+00:00 cpan Things I like. http://use.perl.org/~elliot/journal/36431?from=rss <a href="http://galumph.com/code/perl/module-endorsements.html">They make me happy.</a> elliot 2008-05-15T18:01:07+00:00 others Perl::Critic policies in the DarkPAN. http://use.perl.org/~elliot/journal/36331?from=rss I'm curious about any people who've written custom Perl::Critic policies that aren't on CPAN. <p> What sorts of things are these for? </p><p> Have you had a look at Perl::Critic 1.082? Have you read <a href="http://search.cpan.org/dist/Perl-Critic/lib/Perl/Critic/DEVELOPER.pod">Perl::Critic::DEVELOPER</a>? What do you think?</p> elliot 2008-05-05T19:05:15+00:00 modules This is my Perl blog... http://use.perl.org/~elliot/journal/36283?from=rss ... there are many others like it, but this one is mine. elliot 2008-04-29T23:04:12+00:00 journal The single most useful perlcritic command-line option. http://use.perl.org/~elliot/journal/35963?from=rss For me, it's <code>--single-policy</code>. <p> Generally, Perl::Critic is being used indirectly via a test using Test::P::C or Test::P::C::Progressive, with a <code>perlcriticrc</code> file that is in the distribution's <code>t/</code> directory. </p><p> The most common reason I have for running <code>perlcritic</code> 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. </p><p> <code>--single-policy</code> overrides all other selection criteria for policies. Its value, like the ones for the <code>--include</code> and <code>--exclude</code> options, is used as a regex applied against policy names with the<nobr> <wbr></nobr>/i,<nobr> <wbr></nobr>/m, and<nobr> <wbr></nobr>/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 </p><p> <code> perlcritic --single-policy english<nobr> <wbr></nobr>.</code> </p><p> 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.</p> elliot 2008-03-23T16:32:40+00:00 journal Writing configurable Perl::Critic Policies. http://use.perl.org/~elliot/journal/34470?from=rss <p>As of <a href="http://search.cpan.org/dist/Perl-Critic/">Perl::Critic</a> 1.07, I would like to discourage the creation of constructors for Policies. Instead, I would encourage the use of <a href="http://search.cpan.org/dist/Perl-Critic/lib/Perl/Critic/Policy.pm#initialize_if_enabled">P::C::Policy::initialize_if_enabled()</a>. The reasoning is twofold. </p><p> 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. </p><p> 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 <a href="http://search.cpan.org/dist/PPI/lib/PPI/Element.pm">PPI::Element</a>. </p><p> This originated from <a href="http://use.perl.org/~ChrisDolan/">Chris Dolan's</a> work on the Perl Foundation grant to create the remaining Policies that can be implemented that enforce one of the ideas in <a href="http://www.perlfoundation.org/perl5/index.cgi?PBP">PBP</a>. Specifically, for <a href="http://search.cpan.org/dist/Perl-Critic/lib/Perl/Critic/Policy/Documentation/PodSpelling.pm">Documentation::PodSpelling</a>, but this change has been made to all the configurable core Policies. In particular, this helps <a href="http://search.cpan.org/dist/Perl-Critic/lib/Perl/Critic/Policy/CodeLayout/RequireTidyCode.pm">CodeLayout::RequireTidyCode</a>. </p><p> Differences from a constructor other than the obvious first parameter: </p><ol> <li>The configuration is passed in as a hashref and not a hash.</li><li>initialize_if_enabled() returns a boolean specifying whether the Policy should be enabled.</li></ol><p> This is how the two above policies bow out. </p> elliot 2007-09-17T01:55:39+00:00 modules Lesson of the day: Readonly, Exporter, and subroutine sigils http://use.perl.org/~elliot/journal/34377?from=rss <p> They don't get along. </p><p> As of the recent 1.07 release, <code>Perl::Critic</code>, has started using <code>Readonly</code> to be more more self-compliant with <cite>Perl Best Practices</cite>. We had been avoiding use of <code>constant</code> for the reasons described in the book, but had not been willing to add the <code>Readonly</code> dependency until now. </p><p> The <code>Perl::Critic</code> coding standard has been to use sigils for subroutines in <code>@EXPORT_OK</code>, etc. and import lists, but <code>Exporter</code> 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. </p><p> Explicitness: 0, Keyboard laziness: 1.</p> elliot 2007-09-07T22:04:30+00:00 journal