Re: Request for Comments on Perl::Critic

I looked at the first subroutine of Perl::Critic (sub new), and I noticed that it violates several of PBP's recommendations. For instance, while the API of sub new uses named arguments, it doesn't say all of them need to be passed in a hash ref. It also uses hash based objects, instead of using Class::Std. I also note regexes without a /s modifier, and even at least one without any modifier.

I started installing Perl::Critic, but it has an army of dependencies - when it way up in the dependence tree had dependencies on ExtUtils::AutoInstall and CPANPLUS, I aborted the process.

Perl --((8:>*

Comment on Re: Request for Comments on Perl::Critic

Replies are listed 'Best First'.
Re^2: Request for Comments on Perl::Critic by friedo (Prior) on Nov 01, 2005 at 13:59 UTC
PBP is a great book and while I have nothing but immense respect for TheDamian, I think he goes a little off the deep end in parts of it. When reading it, I found that about 80% of it consisted of things I already do, 15% consisted of things that might be a good idea, and 5% consisted of things that made me say, "What the hell* is this nutcase thinking?!*" But that's OK. Nobody agrees on coding standards, and in Perl especially, because there's a million ways to do everything. I like to think my code is clean, abstract, modular and well-organized, but I'm sure Damian would be horrified by some of my decisions. ("Oh no! friedo uses `unless` all over the place! He must be a drooling mental patient!) You get the idea. That said, I don't think PBP is a good baseline to use for a code critic. A lot of the reccomendations are somewhat superficial, whereas a code critic should look primarily at dangerous constructs. (Non-use of `strict`, indirect method invocation, accidental autovivification, symrefs, overly complicated conditionals, etc.)	[reply] [d/l] [select]
Re^2: Request for Comments on Perl::Critic by tirwhan (Abbot) on Nov 01, 2005 at 13:24 UTC
Ooh, interesting! Does not following PBP constitute a failing that should be flagged in and of itself? (I'm not being facetious here, I'm genuinely interested in what people think about this.) If so, to what degree? While I think PBP is a fantastic book, there are (to my mind) certain recommendations in it which can/should be ignored more readily than others and regarding the whole book as a "must-follow" sort of bible would pose more restrictions on module authors than I personally think sensible. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply]
Re^2: Request for Comments on Perl::Critic by jthalhammer (Friar) on Nov 02, 2005 at 22:01 UTC
The Perl::Critic distribution is fully self-compliant. If you have Test::Perl::Critic installed, then it automatically critiques itself during the build. But I'm just like everyone else who has read PBP: there are some practices that I'm still working to adopt and there are some that I completely reject. Does this make Perl::Critic a heretic? I don't think so. Regardless of how it is actually written, the idea behind Perl::Critic is to help developers follow clear and consistent coding practices. It doesn't actually matter what those practices are. I just chose to start with PBP becuase they are well known and come from a reputable source. Any developer is free to create Perl::Critic::Policy modules that enforce their style and practices. -Jeff	[reply]