Re^2: Commonly accepted style guide?

A recent module, Perl::Critic, has a nice command line interface ( perlcritic) that tells you which of Conway's "Perl Best Practices" your code might be violating.

For example:

$ perlcritic `perldoc -l Time::HiRes`
Package variable declared or used at line 4, column 1. See pages 73,75
+ of PBP.
Deprecated 'require' statement used at line 6, column 1. Use 'use' pra
+gma instead
Deprecated 'require' statement used at line 7, column 1. Use 'use' pra
+gma instead
Code before warnings are enabled at line 9, column 1. See page 431 of 
+PBP.
String form of 'eval' at line 20, column 12. See page 161 of PBP.
Useless interpolation of literal string at line 25, column 9. See page
+ 51 of PBP.
Postfix control 'if' used at line 25, column 46. See pages 93,94 of PB
+P.
Postfix control 'unless' used at line 42, column 27. See pages 96,97 o
+f PBP.
Builtin function called with parens at line 42, column 34. See page 13
+ of PBP.
[download]

If you aren't brave, don't do that with CGI. :)

Comment on Re^2: Commonly accepted style guide? Download Code

Replies are listed 'Best First'.
Re^3: Commonly accepted style guide? by BUU (Prior) on Sep 25, 2005 at 09:39 UTC
Just from that output, that looks like quite possibly the most useless piece of code ever written. Require is now deprecated? We can't call builtins with parentheses? Postfix ifs are bad? Since when?!	[reply]
Re^4: Commonly accepted style guide? by holdyourhorses (Monk) on Sep 25, 2005 at 10:12 UTC
If you read the book, you may agree on a certain practice, and therefore use perlcritic to check that your code is adhering to it. If you disagree (but you should at least read it before saying so) you can always disable the checking of that rule in perlcritic. The rationale of the book, and of percritic as well, is to ensure that a group of programmers use a consistent set of rules. And "a group of programmers" could be you and the one maintaining your code 6 months from now, and that could be you again. I personally disagree with some of Conway's recommendations, but I like the principle.	[reply]
Re^4: Commonly accepted style guide? by jthalhammer (Friar) on Nov 01, 2005 at 06:42 UTC
In my defense, I have to argue that Perl::Critic is far from useless. It is simply a source-code analyzer that is similar to the kinds of tools that Java and C(++) have had for years. I used Conway's book as a reference, but Perl::Critic is very customizable and lets you choose the rules you want to follow. And it is extensible so you can easily add new rules that suit your own tastes. In my organization, we have several Perl developers with different backgrounds and different levels of skill. As a result, a large portion of our maintenance effort is spent dealing with all the idiosyncracies and coding habits of each developer. I wrote Perl::Critc to help level the playing field. By giving every developer a consistent set of rules to follow, we can focus on delivering software instead of struggling with each other's quirks, preferences, and deficencies. You may not agree with Conway's guidelines, but Perl::Critic doesn't insist that you do. I'm sure you have your own ideas about how to do certain things in Perl. So I invite you to publish your own Perl::Critic::Policy modules and let others benefit from your wisdom. -Jeff	[reply]


Think about Loose Coupling
	PerlMonks