Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
XP is just a number
 
PerlMonks  

Re: Perl Best Practices

by siracusa (Friar)
on Aug 06, 2005 at 17:06 UTC ( #481519=note: print w/ replies, xml ) Need Help??


in reply to Perl Best Practices

I'm not done with the book yet, but the style chapter in particular was a bit like instructions on "how to program like Damian." I guess there's simply no way to cover all stylistic options, and so Damian's choice to present a single, self-consistent style (his own) is understandable. I just wish there'd been more detail in his reasoning. In a few cases, he dismisses alternatives and explains his own choice in a very facile way.

Time and space restrictions explain that a bit, but even within the bounds of his own recommended style, I wanted to see more exploration of the inherent tensions within his style. For example, his preference for a 4-space indent, non-abbreviated variable names, and very clearly spelled-out subroutine names is slightly at odds with his line length recommendations.

Similarly, many of the later style rules are consequences of earlier ones. This is fine, and expected, but I wish it was explicitly stated. For example, the choice of K&R braces dictates the continued statement style (e.g., starting continued assignment lines with "=") and the other rules that are meant to disambiguate an indented line from a new scope.

Overall all, though, the introduction does an excellent job of explaining how to make the most of the style section: even if you disagree with a style guideline, just use it as a means to explore the reasoning behind your own style choice in that area.

There's one case that (IIRC) he didn't cover, however, when it comes to changing your own style. I have a personal, totally stupid and arbitrary habit of using parens with single-variable "my" statements *only* when I'm pulling off @_ args in a subroutine. (Everywhere else I just do "my $var") I'd like to stop doing it, because it's pointless and inconsistent, but then I'm faced with the problem that all of my new code would suddenly be inconsistent with my old code. And since the habit is not really harmful, I can't bring myself to break the consistency of my own code.

I imagine this applies to anyone contemplating a style change. So how, do you do it? Do you go back and update all your old code to fit the new style? Or do you just grit your teeth and move forward? Anal-retentive programmers need help in this area! ;)


Comment on Re: Perl Best Practices
Re^2: Perl Best Practices
by WillC (Initiate) on Jan 30, 2012 at 12:28 UTC
    my $x = ( 1, 2, 3 ); my ($y) = ( 1, 2, 3 ); say $x; say $y; ... gives different results for the two styles if more than one thing is passed. So I'd stick with my ($x) = ...

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (11)
As of 2014-04-19 09:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (478 votes), past polls