Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
3) Always start your elsif or else block on a new line.

That seems to be a pure stylistic choice, cuddled else don't decrease robustness, efficiency or maintainability -- they just make some diffs a tiny bit larger.

9) Never use $_ or the invisible equivalent.
Always define your own variable in a foreach loop. Never use print or /regex/ with the invisible $_.

That's just stupid. If the scope for $_ is small, there's no reason to avoid it. Even more, if you don't want to use $_, you are doomed not to use map, grep and friends from List::Util. Which can make code much more maintainable.


my @filtered = grep /someregex/, @original;


my @filtered; for $str (@original) { if ($str ~~ /someregex/) { push @filtered, $str; } }

I for one find the first one much more readable and maintainable, because it has less boilerplate code.

Unless and until could be very confusing.

They could be, if you used them in a stupid way. Like with a negated condition. But so could be the if and while equivalents. I agree about unless and else blocks though.

What I don't like about your list is that it forces people to write very unperlish code, and (implicitly) forbidding map and grep seems like you are afraid of their power. Maybe that's because you haven't understood them yet?

Anyway, here are my top 3:

1) Don't do stupid things

It's usually pretty obvious if code will be hard to maintain later on. Convoluted call graphs, 50-char regexes without whitespaces and excessive use of magic literals all indicate that you don't want to end up maintaining the code. So don't do that. But you don't need a rule for everything if you apply your common sense.

Which brings me to my second point:

2) Think about what you write

That one is pretty obvious, no?

3) Be consistent

In many ways it doesn't matter much how exactly your programming style looks like, as long as it's consistent. If you don't code alone, make sure to agree on some style with your peers.

In reply to Re: 20 most important Perl Best Practices by moritz
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
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others making s'mores by the fire in the courtyard of the Monastery: (7)
    As of 2018-06-25 18:31 GMT
    Find Nodes?
      Voting Booth?
      Should cpanminus be part of the standard Perl release?

      Results (128 votes). Check out past polls.