Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
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.

In reply to Re: 20 most important Perl Best Practices by aaron_baugher
in thread 20 most important Perl Best Practices by greengaroo

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    [pryrt]: The mismatched ones have a Jan 23 2017 Last-Modified header -- I wonder if they rezipped them and forgot to update the sha1
    [stevieb]: RT ticket for the csum mismatch of various versions of Strawberry Perl

    How do I use this? | Other CB clients
    Other Users?
    Others scrutinizing the Monastery: (3)
    As of 2017-03-29 21:10 GMT
    Find Nodes?
      Voting Booth?
      Should Pluto Get Its Planethood Back?

      Results (353 votes). Check out past polls.