Re: Where are the Perl::Critic policies for the Camel?

[petdance]

Some thoughts from someone who has written a number of P::C policies:

1. The policies that get written are the ones that scratch an itch. I've never written a policy for foreach (<INPUT>) because I've never worked on a codebase where someone had written that. Vague names like $data? That's something I watch out for.
2. It's really pretty easy to write a policy. The infrastructure is there and the testing is easy.
3. The way I have perlcritic policies in my project is to have a .perlcriticrc in the root of the project and then have a "make critic" target.
4. Severities are something I pretty much ignore. I see warnings mostly as binary. They're either there or they're not. If a project has so many of a given warning that it's not worth my time to flag it (say, on unnecessary string interpolation which is a pet peeve of mine but sometimes just something you have to live with), then I just turn it off in my perlcriticrc rather than have all the noise.
5. P::C is not fast. When you have a small number of files you want to check before committing to your VCS, it's plenty fast. Running across, say, 5,000 files in a big project as a regular thing? That can take a while.
6. Join the PC dev list. We'll be more than happy to have your input and to help guide.