[Montreal-pm] Perl critic

[Olivier Bilodeau]

On 05/20/2012 12:10 PM, Christian Lavoie wrote:
> Does everybody maintain their own set of policies for critic? Or not
> bother using it all?

We use the default except for:

[Perl::Critic::Policy::BuiltinFunctions::ProhibitStringyEval]
allow_includes = 1

But we don't rely on perlcritic much right now but hope to use it more
and more in the future.

There's a very good FLOSS Weekly podcast by the author Jeffrey
Thalhammer here: http://twit.tv/show/floss-weekly/189. Probably not that
relevant only to use it but interesting to hear about the context and all.

In the podcast he mentions Test::Perl::Critic::Progressive
(https://metacpan.org/module/Test::Perl::Critic::Progressive) which
allows you to gradually increase an old codebase to perlcritic
compliance during the test runs (and then you can crank up your severity).

> 
> I find myself writing yet another quick shell script to wrap the basic
> utility with a policies selection that makes sense (RCS keywords,
> seriously? Let alone in 2012?) -- what do y'all do to enforce coding
> style anyway?

For style, we use a simple script that looks for tabs. It's the only
policy we have right now. The rest is done through code review. Not
because we know better but because so far only tabs caused real problems
(patch management problems).

I would imagine automating source code formatting with perltidy either
at the gatekeeper level or in source control pre/post commit hooks is
possible but maybe a little harsh.

-- 
Olivier Bilodeau
obilodeau at inverse.ca  ::  +1.514.447.4918 *115  ::  www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)