[sf-perl] Perlcritic startup.
fred at redhotpenguin.com
Thu May 6 12:06:50 PDT 2010
On Wed, May 5, 2010 at 5:34 PM, George Hartzell <hartzell at alerce.com> wrote:
> I'd like to start playing with Perl-Critic. It seems to be extremely
> flexible (even by Perl TMTOWTDI standards).
> As I wade in and start exploring options I've realized that it might
> be really useful to hear how other folks use it (policies, severities,
> where/when you use it (svn hooks, etc...)).
> Anyone want to share?
I've worked on a couple of projects that used Perl-Critic and here are
my biggest takeaways:
1) Subversion pre-commit hooks are great, but having your checkins
rejected for compliance burns a lot of developer time. Reject
checkins for only the most egregious violations (use of map in void
context, etc.). If you have the skills, refactor the code
automagically with a subversion wrapper and then check it in. I wrote
a proof of concept a while ago to do this, but wondered how deep the
rabbit hole went to make it work across lots of policies.
2) You can't please all the developers all of the time. Start off
with the default policies and live with it for a couple of months
before considering custom policies. You can argue endlessly about
whether globals should be $lowercase, $CamelCase, or $UPPERCASE, and
most of those arguments will burn developer time and produce limited
3) This is somewhat off topic but when you have hooks in place for
perlcritic, perltidy hooks often get added in too. Write a subversion
wrapper which perltidies the code into a new file and checks that in.
Code formatting should happen automatically. If you have to run
'perltidy file.pl' or \ry in vim or perlnow-perltidy in emacs then you
burn developer cycles (a small number but it adds up in the long
More information about the SanFrancisco-pm