Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^2: Commonly accepted style guide?

by holdyourhorses (Monk)
on Sep 25, 2005 at 07:22 UTC ( #494879=note: print w/ replies, xml ) Need Help??

in reply to Re: Commonly accepted style guide?
in thread 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.

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?!

      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.

      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.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://494879]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2016-02-11 01:01 GMT
Find Nodes?
    Voting Booth?

    How many photographs, souvenirs, artworks, trophies or other decorative objects are displayed in your home?

    Results (357 votes), past polls