Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
I don't have any references to any formal specifications, but here's what I've gleaned from my experience working on some large Perl projects:

1. Always always always "use strict".

2. Use the "-w" flag during development (if not production) to catch any odd behavior.

3. When using OO, don't consolidate multiple modules into one file. Each module should have its own file, named after the module itself, in a respective directory. What this means is that the module Foo::Bar::Baz should be in the directory Foo/Bar, and have a filename of

4. Also when using OO, you might want to not corrupt the main Perl lib tree. Typically (under a Unix-ish system), you would want to keep your program in an /opt directory, such as /opt/foo. I would suggest creating an /opt/foo/lib to keep your Perl modules in. You can then, in each script which uses these modules, add the following lines:

BEGIN { require '/opt/foo/.perlpath' if -e '/opt/foo/.perlpath'; }
/opt/foo/.perlpath would then contain:

use libs qw(/opt/foo/lib);
This will allow you to port your application from host to host, without having to recompile perl to see your modules, and without having to polute the common perl library directories, which your application's respective user id does not own.

5. You should definitely settle on OO structure, such as only allowing access to data through getter and setter methods, as well as how you will address private and public methods (private is usually denoted as having a "_" in front of the method name, such as "_findStuff").

6. I would also recommend coming up with common utilities, used throughout the code so that you don't have developers writing the same thing twice or, worse yet, copying and pasting code. Look at CPAN for logging modules and other common modules which will be used by developers.

7. Standardize on your logging! This is the only thing that will save you in a production environment to help diagnose a problem.

8. Remember that, although there is more than one way to do it, this should not necessarily be the case on a large-scale Perl project. Readability and maintanability should come before artistic freedom.

Good luck!

In reply to Re: Perl Style Guides for Large Projects by Anonymous Monk
in thread Perl Style Guides for Large Projects by da

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 lurking in the Monastery: (6)
    As of 2018-06-25 19:35 GMT
    Find Nodes?
      Voting Booth?
      Should cpanminus be part of the standard Perl release?

      Results (128 votes). Check out past polls.