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 Baz.pm.

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';
}
[download]

/opt/foo/.perlpath would then contain:

use libs qw(/opt/foo/lib);
[download]

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!

clifford-perlmonks@330software.com

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.