note
Anonymous Monk
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:
<br><br>
1. Always always always "use strict".
<br><br>
2. Use the "-w" flag during development (if not production) to catch any odd behavior.
<br><br>
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.
<br><br>
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:
<br><br>
<code>
BEGIN
{
require '/opt/foo/.perlpath' if -e '/opt/foo/.perlpath';
}
</code>
/opt/foo/.perlpath would then contain:
<br><br>
<code>
use libs qw(/opt/foo/lib);
</code>
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.
<br><br>
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").
<br><br>
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.
<br><br>
7. Standardize on your logging! This is the only thing that will save you in a production environment to help diagnose a problem.
<br><br>
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.
<br><br>
Good luck!
<br><br>
clifford-perlmonks@330software.com
209555
209555
14