in reply to Commonly accepted style guide?

Just to fill in the background a bit... our discussion, or at least my part of it, centered entirely around the word "violation." A style "violation" assumes some sort of accepted coding standard and there can be no violation in the absence of one.¹ Even a "community style guide" would not resolve the issue as one would have to accept that guide before we could say he had any "style violations"

I agree with dragonchild's assessment of the PerlMUD code, by the way. I'd just label it "exceedingly poor style" rather than make claims about "violations". Perhaps I have an issue with authority. :-)

In any case, I do believe there are certain de-facto standards that exist for Perl code among those who aren't writing Perl in a vacuum. This has come up here before. (I'll post a node link here later. later: Here it is: My coding guidelines. Those are Abigail-II's coding guidelines, btw. Not mine.) And Best Practices seems to address this pretty head-on. For those who use it, Perltidy addresses at least some style issues in a more hands-on way.

[1] I make one exception: inconsistency is always a style violation. If it isn't consistent, it isn't a "style" at all.

-sauoq
"My two cents aren't worth a dime.";

Replies are listed 'Best First'.
Re^2: Commonly accepted style guide?
by holdyourhorses (Monk) on Sep 25, 2005 at 07:22 UTC

    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. :)

[reply]
[d/l]
      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]

        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]
        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]

In Section Meditations