Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re: 20 most important Perl Best Practices

by aaron_baugher (Curate)
on Aug 22, 2012 at 22:40 UTC ( #989163=note: print w/replies, xml ) Need Help??

in reply to 20 most important Perl Best Practices

1) Place a semicolon after every statement.
Agreed; if I come back to add another statement later, I don't want to have to look and see whether the formerly-last statement has a semicolon yet. Same reason applies when always following the last item in a list with a comma. (The inability to use that trailing comma is reason #853 why I hate PHP.)
2) Never place two statements on the same line.

Eh. In most cases, yes; but when I have two or more small statements that go together as a set, it's clearer to me if I put them together on one line. For instance, if setting a set of 3D coordinates:

$x=3; $y=4; $z = 5; # or maybe better ($x, $y, $z) = (3, 4, 5);

Of course, the second one is a single statement with three effects. But can you really say it's okay and the first one is bad? To me, either one makes it very clear that the items are a set, and the statements are short enough that it saves space without getting overly dense.

3) Always start your elsif or else block on a new line.

Get thee behind me. I hate, hate, hate curly brackets on their own line, unless at the end of a complete block ( and that's only because I don't know where else to put it). I have no idea why I'd want to use up 8 lines on this ode to whitespace:

if(match) { do_this(); } else { do_that(); }

when I can do this:

if(match){ do_this(); } else { do_that(); }

I have more trouble seeing the flow in the first example than the second, and it takes up more space in my terminal. I know, this is one of those personal style things, so I'm not going to try to convert anyone else to the One True K&R Way. But please don't tell me the first example is better. It's not.

4) Always use a label on loops when using next, last and redo.

This way, if you later add another embedded loop around your next, last or redo statement, your code will not break, it will still act on the outer loop, not the new inner loop. Also, it helps readability.

Bah. In the extremely unlikely event that I discover that a loop needs an inner loop I hadn't thought of (I've wrapped an existing loop inside a new one before, but I don't think I've ever needed to go the other way around), I'll notice these statements while I'm re-indenting. If my loop is so long that a next unless $something; can hide from me, it probably needs to be redone anyway. And really, thanks to Perl's map, grep, and hash lookups, nested loops are rare enough (in my work, anyway) that I'm not going to add some extra typing to all my loops because it might end up coming in handy for the one-in-a-thousand of them that are nested.

CamelCase is preferable over uppercase, unless it is an acronym. Never use all lowercase. Never use underscore.

Preferable for whom? I don't like any of them, honestly, so I tend to keep my variables to single words and acronyms as much as possible. I prefer the clarity of the underscore look, but hate typing shifted characters when I don't have to. CamelCase is ugly and gives me Java flashbacks. Stringing lowercasewordstogether isn't very legible, but least offensive to me. Sometimes I wish I could use a hyphen in variable names, as in Emacs.

9) Never use $_ or the invisible equivalent.

Bah again. Yes, I know $_ can bite you in certain circumstances. But consider the following:

while(<DATA>){ chomp; next unless /\w/; s/foo/bar/g; say; } while(my $line = <DATA>){ chomp $line; next unless $line =~ /\w/; $line =~ s/foo/bar/g; say $line; }

Please don't tell me that the second one is better. It's more cluttered, so harder to read, and the extra variable introduces five more opportunities for typos -- seven if you count the need to include the =~ operator explicitly now. Avoiding $_ at all times because you fear stumbling across one of those odd circumstances where it's a problem (without recognizing it) is like wearing a steel helmet whenever you go outside because you're afraid of meteorites. $_ is one of Perl's best features. Use it without fear; just know how.

11) Always use if blocks, never postfix if statements as a one-liner.

There is an exception to this rule: when using flow of control commands.

So I shouldn't say:

calculate_time($date) if defined $date;

? I'd probably reword that to say something like, "Don't use postfix modifiers after complex or multiple statements." I wouldn't do the following, because I'm not sure how the precedence would work or if they'd even compile:

do_this(), do_that if $match; do_this($_) for @items if $match;
13) Use unless and until as little as possible.

I don't see why. One of the beauties of Perl (intentional, I think) is the ability to write things similarly to the way you'd say them in your native language. If the process I'm thinking in my head is, "Do this unless the Found flag is set," then I don't see why this isn't the best way to code that:

do_this() unless $found; # surely you're not suggesting this is better, are you? do_this if not $found;

All the other guidelines seem fine to me.

Aaron B.
Available for small or large Perl jobs; see my home node.

Replies are listed 'Best First'.
Re^2: 20 most important Perl Best Practices
by tobyink (Abbot) on Aug 24, 2012 at 16:25 UTC

    "I don't see why. One of the beauties of Perl (intentional, I think) is the ability to write things similarly to the way you'd say them in your native language."

    ... if your native language happens to be English. :-)

    perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

      ... if your native language happens to be English. :-)

      Or Latin

      Heh, I originally wrote "English," but then I changed it to be less Anglo-centric. :-) But now that you mention it, I suppose spoken languages with different word order might not translate as well into idiomatic Perl.

      Aaron B.
      Available for small or large Perl jobs; see my home node.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://989163]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (8)
As of 2018-06-21 15:16 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (118 votes). Check out past polls.