[Melbourne-pm] Do you run advanced lint scripts over your perl as part of a code review/release management process? (Was: Re: ISO 9126 and automated testing)

[Scott Penrose]

I have implemented the following scripts as a matter of course in my  
new CPAN modules:

#scottp at Muffin:514:~/dd/zaltana/Gallery$ cat t/criticise.t
use Test::More;
eval 'use Test::Perl::Critic (-profile => "t/perlcriticrc");';
plan skip_all => 'Test::Perl::Critic required to criticise code' if $@;
all_critic_ok();

#scottp at Muffin:515:~/dd/zaltana/Gallery$ cat t/pod.t
use strict;
use warnings;
use Test::More;
eval "use Test::Pod 1.14";
plan skip_all => 'Test::Pod 1.14 required' if $@;
plan skip_all => 'set TEST_POD to enable this test' unless $ENV 
{TEST_POD};
all_pod_files_ok();

#scottp at Muffin:516:~/dd/zaltana/Gallery$ cat t/podcoverage.t
use strict;
use warnings;
use Test::More;
eval "use Test::Pod::Coverage 1.04";
plan skip_all => 'Test::Pod::Coverage 1.04 required' if $@;
plan skip_all => 'set TEST_POD to enable this test' unless $ENV 
{TEST_POD};
all_pod_coverage_ok();


My plan is to also add code coverage tests - although then we are  
really moving into non syntax testing.

Note though, that I do not believe 100% in some of the above, e.g.  
some of the Critic entries. I am in the process of reducing some of  
those tests, here is my config file so far:

#scottp at Muffin:519:~/dd/zaltana/Gallery$ cat t/perlcriticrc
# I hope to change this so that it uses Perl Tidy to convert to  
spaces before
# test and commit.
[-CodeLayout::ProhibitHardTabs]

# Inline pod is better
[-Documentation::RequirePodAtEnd]

# postfix unless/if is very useful in control/flow & parameter  
checking - as it
# says in PBP - but the rule doesn't care - so removeit for now.
[-ControlStructures::ProhibitPostfixControls]

# Unfortunately sometimes it is necessary to use () around builtin
# Split just looks plain stupid without it.
[-CodeLayout::ProhibitParensWithBuiltins]


As you can see - I keep comments on why I have changed them, and in  
many cases hope to remove them. Tabs is a classic one - I use them,  
and the lovely part of it is that I can then cope with reading  
horrible 4 space or 2 space files files (for some reason my brain  
doesn't see 2 or 4 spaces down a page and misinterprets them) - but I  
totally understand the reasons - so I use tabs and convert to 4  
spaces on upload to CPAN which sort of gives me best of both worlds.

I am also unsure as yet how to limit perl critic on "on purpose  
hacks" - many cpan modules that do tricks of perl to achieve  
something (ala NEXT) don't pass the perl critic, and fair enough - so  
the point is you move that hack to an external module, but therefore  
I have to skip critic on that one :-)

Hope that helps a little.

BTW. I believe Crash does a Perl Critic on CVS commit - so you can't  
even commit code that does not pass - not a bad idea, I think I like  
the idea of marking branches at levels of stability - so you can't  
commit broken code to a beta or stable branch - but you can to alpha  
or head. Something like that.... hmm.... might have to play around  
with Subversion a bit more.

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.pm.org/pipermail/melbourne-pm/attachments/20060630/aa1ce18f/attachment.bin