Chris Dolan recently received a Perl Foundation Grant to write 20 new policy modules for Perl::Critic. I managed to catch up with Chris by email and ask him a bunch of questions about his work on Perl::Critic, the TPF grant, and more.
Kirrily: So, how did you first get involved in Perl::Critic?
Chris: Funny, I had to look back at my email to remember this. You’d think I could remember two years ago…
I read Damian Conway’s Perl Best Practices (aka PBP) in summer 2005 and thought, “Finally! The solution to the ‘Perl is not readable’ myth!” I tried applying all of the ideas manually in a new module I was just about to release to CPAN (Net::IP::Match::Regexp). I found the process rewarding, but a little tedious and error-prone.
After working with the PBP recommendations manually, I thought about writing some code to judge some of the recommendations automatically, but happily I decided to check CPAN first. I found Perl::Metric::Basic and posted some RT reports. Then I found Perl::Critic, which had just been renamed from Perl::Review. I found the code much more approachable that Perl::Metric and soon filed a few RT reports and a cpanratings review. Jeff Thalhammer, the P::C creator and leader, emailed me back personally thanking me for the feedback. After that, we had about a dozen back-and-forths where Jeff sent me pre-release tarballs of Perl::Critic and Test::Perl::Critic to test before sending them to CPAN. Then, I wrote my first from-scratch policy (Modules::RequireEndWithOne) about a month later, and I was hooked.
Kirrily: What prompted you to apply for a TPF grant? How did you convince them to give you money? How did you find the grant process?
Chris: I hope nobody criticizes me for admitting this, but my reason for applying for the grant was self-motivation. Our second child was born Jan 1, 2007 and the company where I worked was struggling, so it was a hard time to find energy for my open source efforts. I usually work best under pressure, so I decided the publicity of a TPF grant would force me to get something done (and the money will be a nice bonus too).
I wrote a ton of grant proposals in my former life as an astronomer and, of course, tons of business proposals as a web/programming consultant, so I found the TPF grant process pretty easy. The positive impact of Perl::Critic is obvious on the community of people who care about good Perl code, so the justification part was straightforward. The harder part was deciding what part of P::C to
propose to build.
Kirrily: Is there a theme or themes to the 20 modules you’re doing?
Chris: Yep. We keep an extensive TODO.pod file in the P::C svn repository. One portion of that file is devoted to PBP recommendations that seemed feasible to implement in code. I had created that list over a year earlier by paging through the PBP book and brainstorming implementations for each recommendation. Needless to say, some of the PBP recommendations will never make it into P::C — for example “Never assume warning-free compilation implies correctness” (page 432).
It turned out there were an even 20 PBP-based ideas in the TODO list (vs. about 40 non-PBP ideas). Twenty seemed like a nice round number and a challenging-but-doable quantity. At that time, I was primary
author of 27 of the 93 finished policies, so I had a pretty good idea of what was involved.
Kirrily: Why should people use Perl Critic? Why shouldn’t they?
Chris: In my opinion, it’s good for two things:
1) Finding bugs (real bugs and potential bugs)
2) Making your code more approachable
Both are especially important for open source code that might be used by thousands of other programmers. Why write bad open source code?
One reason not to use Perl::Critic is to put a badge of honor on your code. Achieving P::C compliance is a good thing to announce to the world because it tells users that you care about the quality and consistency of your code. But P::C doesn’t help make your code better directly. It just tells you that your code isn’t broken in one of about 100+ known ways. And some of those 100+ contradict each other! Compare that to the innumerable ways to write bad code. So, you’ve got to start with good code and use P::C as a tool to make it a little better.
One piece of advice I like to share is that you should not be afraid to turn off P::C policies that don’t work for your code. I think Damian gave similar advice in PBP. In the P::C code itself, we have 98 instances of
## no critic(...) which turns off certain policies. Even Perl::Critic is not 100% Perl::Critic compliant! But
98 out of 27,000 lines of code isn’t bad.
Another controversial topic is whether
.t files should be P::C compliant. Personally, I don’t bother. Writing test code needs to be fast and easy or it falls by the wayside.
Kirrily: Do you know of any really interesting uses of P::C out there? Famous companies using it?
Chris: Good question. We should ask Jeff Thalhammer about that — as P::C founder, he has a closer connection to our user community. There was brief talk about creating a for-profit consulting entity to help big companies write better code using P::C, but I don’t think anything came of that (I was too busy to participate).
What I find interesting is the people/groups/companies who have privately implemented their own policies for P::C. Parrot, for example, had a few custom policies the last time I looked. Another example is MathWorks, who funded the Perl::Critic developers to write some specific policies they desired. Now that’s a business model any open source developer craves!
Kirrily: What next after you’ve implemented these P::C modules?
Hmm, I have no real plans. More policies, I guess. I’d love to get more people writing them. They aren’t too hard to create and without them P::C is worthless. If anyone wants to get involved, I’d be happy to be a mentor. Giving fish vs. teaching fishing, y’know.
In my day job, I do a lot of Java coding (and often enjoy it). We use a commercial package called CodePro by Instantiations which is conceptually similar to Perl::Critic but is much more polished. They have over 900 policies to choose from, many of them specifically designed to squelch anti-patterns in the big APIs like Spring, Hibernate, Struts, etc. Jealously, I’ve often thought that they have an easier job than we do because Java is so much easier to parse than Perl, and the code smells seem to fall in more easily identifiable patterns.
When Perl 6 becomes popular, I’d like to see Perl::Critic be implemented against it. Perl 6 will have a grammar that is much more amenable to grepping. Behind the scenes, I’d like to see the Perl 6 version of P::C work against de-sugared syntax or perhaps even the abstract syntax tree to simplify the policy writing. Unless a huge amount of work goes into improving PPI, that’s not going to happen for Perl 5. At one point, we talked about writing P::C policies using an XPath-like notation, but nobody ever championed that goal.
I discovered that FindBugs (another Java code analysis tool) took that approach successfully. Maybe P::C can benefit from the Parrot tree grammar engine (TGE). Or the optimizer. After all, the syntax
pattern matching that P::C has to do is not that different from the opcode pattern matching that an optimizer performs.
Overall, what I’d really love is for Perl 6 to avoid the “write-only language” moniker that got slapped on Perl 4 and Perl 5. If P::C can help with that, then it has succeeded.