Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: 20 most important Perl Best Practices

by ww (Archbishop)
on Aug 22, 2012 at 19:51 UTC ( #989126=note: print w/replies, xml ) Need Help??

in reply to 20 most important Perl Best Practices

No downvote; you're entitled to your opinions and local practices, but the only items I can endorse are 1, 2 and possibly 8 ... and even those have exceptions.

As for the rest of the list? Contentious, at best. Some shops will work well with your kind of internal policy; others would turn into hell-holes were they to adopt this kind of rigid (and, in many cases, IMO, ill-advised) rules.

  • 3: Some of us regard nested } else { statements as easily readable. Though trivial, for me, the required, subsequent additional scrolling in't worth the supposed gain.
  • 4: Perhaps a good idea if your shop is mostly full of minimum-wage noobs. The kind of breakage you're trying to avoid isn't generally a problem with skilled programmers given time to work carefully (...yeah, yeah, yeah -- but I'd love to live :) in a more nearly perfect world.)
  • 5, 6 & 7: Again, arguably reasonable as a standardization technique; the specifics, however, are not universally acceptable.
  • 9 & 10: Aw, c'mon. Are your minimum-wage hacks also unable to read code accurately?
  • 11 & 12: Bunkum, IMO, but at least present them as the single point they actually constitute.
  • 13: Well.... maybe. The headline statement is valuable; the narrative wanders off into disputable territory.

Now, how about some items that should be included:

  • use strict; use warnings; (oops, two statements on one line...) UNLESS you are very sure of a good (coding) justification for omitting them!
  • Generally, prefer use warnings over -w because of its limited scope (of course, if incompetents are writing the modules or somesuch, ignore this rule).
  • Indent and break logical sections with an extra newline (yes, I know this is at least to some extent inconsistent with the observation about your 3. "Consistency," a wise man observed, "is the hobgoblin of little minds.") Use white space to make your code easy to follow.
  • (Add some of of many possible guides on commenting.) My own choice would be to tell the programmers to use inline comments only for non-routine syntax or unusual construct (and I would provide some format guidlines: same line? minimum white space between code a # comment..., etc). Advise that the concepts behind most routine comments are better included in documentation, whether plain POD or something more elaborate.
  • Documentation. The programmer(s) should know better than anyone else the high points and the lows; the capabilities and perhaps the shortcuts available to the end user. Don't simply hand that off to tech writers who may or may not have the skills and experience to fully explain your code.

PS: Don't mix as many fonts and styles as I've done here :(

Replies are listed 'Best First'.
Re^2: 20 most important Perl Best Practices
by greengaroo (Hermit) on Aug 22, 2012 at 20:51 UTC

    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.
      +   +

      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.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (3)
As of 2017-11-23 06:41 GMT
Find Nodes?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:

    Results (328 votes). Check out past polls.