First, thank you for your constructive input. It is really appreciated.

Now, to give you a little perspective, the firm I work for does not hire minimum waged developpers, and it's not about trying to manage newbies. In fact, it is so hard to find experienced Perl developpers that the firm hire C++ or Java developpers and train them to Perl. I'm not even kidding. I am not saying everyone being hired is forced to work in Perl, but the group I work with mostly do Perl development, some other groups also use Perl, C++ and/or Java. In my group, we support old applications but we also build new ones, in Perl.

On our systems, not only we have access to all the (approved by the firm) CPAN modules but we have access to all the versions of these modules, build for all version of Perl from 5.8, 5.10, 5.14, in 32 and 64-bits.

So, the best practices I am trying to compile is of course to improve the readability of the code, because it is certain that multiple programmers will work on it, but most importantly, it is a tool for less experienced developpers to avoid pitfalls that could lead to hours of debugging weird issues. Note that we have dozens of different projects, all object oriented, some uses Moose and MooseX syntax, and several projects share dependencies with each others. It is serious stuff we are doing.

With that said, I will add some explainations on the selection of the best practices you are debating.

3: You are right, it is as easily readable but at some point we need to choose one or the other. I hate to see two different styles in the same file. I like the way I mentionned because it adds a natural empty line, and it answers your recommandation: Use white space to make your code easy to follow.

4: This one I added last to my list. I am not sure about it.

5, 6, 7: This is mostly for consistency, since we have multiple developpers working on the same projects. It is debatable, I agree.

9, 10: These are not about readability. In our experience it may lead to very weird problems. We use a lot of callback functions and we often use classes that extend other classes. This one doesn't come from me but it was already in place before I started working here.

11, 12: This is for readability. You are right, I will merge them.

13: OK I will try to re-state the narrative. Got this one from Perl Best Practices.

For the rest, of course we use strict and warnings. It is so obvious to me that I forgot to add it! Indent, break, empty lines, white spaces, etc. I think this is obvious for any language. I may add it as a best practice. Commenting and Documentation too!

Thank you again! Very appreciated!

Take my advice. I don't use it anyway.

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

Title:
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, details, 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, summary, 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.