Perl::Critic for the Camel

Tom C. meditated in Perl Monks that he wants Perl::Critic policies to go with the recommendations from Programming Perl, 4th Edition, Chapter 21.

I started it by creating the perl-critic-policy-camel GitHub repo, which is now a bare distribution structure. Now it can accept pull requests. :)

The next step is probably to make a concise list of the recommendations from Chapter 21, and identify which are covered by existing policies.

I'd love to have this as a "camel" theme, like the "cert" theme I wrote about a long time ago.


What's wrong with just updating PBP?

Yes, it is a different book, by a different author, with different recommendations and that's bad.

It's also very old.

It makes it very difficult to impose a baseline set of practices on a project team.

I can't see anything in the meditation you tagged about updating PBP, but this seems to come up every couple of years and we never move forward.

Does anybody know what the sticking point is? How many of the differences are just because the book is old? You wouldn't expect a 2005 book to have much about Unicode in it. Damian Conway may have changed his mind on some things in the last 8 years.

Does Damian Conway refuse to update it or allow it to be updated? Do O'Reilly refuse to allow it to be updated? Is the problem that the community can't put together a little team of "name" authors to give an update gravitas? Is the problem money?

Is there a feeling that the new Camel book is the new PBP? (I confess I haven't read those sections in any detail, I always refer to PBP.)

I suspect "update PBP" was meant to refer to the PBP critic rules, not the book itself.

It doesn't make sense to shove recommendations from "Programming Perl, 4th edition" into the rule set from PBP, for all the reasons described above (different era, different author, different recommendations). Keep them separate, and let the user decide which he wants to apply to his development practices.

Hey, I still have that. It's basically my full "Perl Best Practices" talk, but I have annotations on a few dozen of the pages about how I'd do it instead.


I enjoyed your book on Effective Programming, I even persuaded a couple of local libraries to stock it. I've got a copy of the latest Camel book here, but I've only dipped into it. Surprisingly, the bit I've read is the bit where you laud the format command to the skies. I suspect that was cut and pasted from the previous edition without proof-reading.

I've never achieved any particular pre-eminence, but I can be reasonably confident that I've worked on more development projects than you. It's one of the few certainties that come from getting old.

Much of what you say there is naive and patronising. I can live with being patronised, but you are patronising the other readers as well.

Very few people in any field take "Best Practices" to mean the one and only true way. They mean "Good Practices" or "Recommended Practices". Even in fields where life and death is at stake, people use the "Best Practices" as a starting point and develop project practices. The difference is that you can end up dead or in prison if you deviate without the appropriate authority.

I did not say, or even imply, that I wanted a single set of compulsory rules.

I said that Perl needed a set of rules about which there was reasonable authoratative consensus and that people could use as a baseline. It does.

You don't want to start developing your project standards from a blank sheet of paper every time. Nor, when you are on a new project, do you want to say "Do this because I am wise". You'll spend ages justifying yourself. It's more likely that you'll want to say "Do this because I've done it before, it's recognised as good practice, and all these people agree with me."

Sometimes you'll want to deviate from the standards, sometimes you won't give a damn about standards.

I did not say, or even imply, that I wanted anybody to do a lot of work for free. I do little bits and pieces for the Perl community for free, but I have no intention of doing a lot. Even with the little bits I do, there is a sub-agenda of networking, job protection, paying back favours, etc. Most people are like that.

It sounds like we need a corporate sponsor. Most discussions of this ilk end with that conclusion.



Leave a comment

About brian d foy

user-pic I'm the author of Mastering Perl, and the co-author of Learning Perl (6th Edition), Intermediate Perl, Programming Perl (4th Edition) and Effective Perl Programming (2nd Edition).