http://www.perlmonks.org?node_id=989140


in reply to Re: 20 most important Perl Best Practices
in thread 20 most important Perl Best Practices

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.
  • Comment on Re^2: 20 most important Perl Best Practices

Replies are listed 'Best First'.
Re^3: 20 most important Perl Best Practices
by ww (Archbishop) on Aug 22, 2012 at 22:31 UTC
    +   +

    However, despite the fact that your response appears well thought out -- in fact, excellent, comprehensive and clear -- I'm not strongly enough persuaded to adopt your package.

    Your objective appears to boil down to 'maintain consistency, across multi-programmer work, across files, and across interdependent packages' (a point on which I'm wholly in agreement) but that's a best practice in itself; most of the details you enumerate are just details and could vary widely from establishment to establishment while still useful as elements informing a local "best practice."

    Speaking of details, the advice I received somewhere, long ago and in a faraway place -- most likely -- that one should use use single quotes rather than double when assigning values, etc, might fit well with your scheme. If nothing else, it tends, for me, anyway, to pay attention to interpolation issues.