Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Perl Style Guides for Large Projects

by Anonymous Monk
on Nov 04, 2002 at 15:49 UTC ( #210197=note: print w/replies, xml ) Need Help??

in reply to Perl Style Guides for Large Projects

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!

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2018-02-17 23:12 GMT
Find Nodes?
    Voting Booth?
    When it is dark outside I am happiest to see ...

    Results (250 votes). Check out past polls.