http://qs1969.pair.com?node_id=209565


in reply to Perl Style Guides for Large Projects

I find the P5EE Style Guide to be an excellent resource. Oddly, it can no longer be found on the P5EE website, but you can find the P5EE Style Guide in Google's cache.

Hope that helps
-Eric

--
Lucy: "What happens if you practice the piano for 20 years and then end up not being rich and famous?"
Schroeder: "The joy is in the playing."

Replies are listed 'Best First'.
Re: Re: Perl Style Guides for Large Projects
by djantzen (Priest) on Nov 01, 2002 at 00:18 UTC

    From a brief perusal of the Slash style guide I see that chunks of the P5EE guide are borrowed directly from it (e.g., sections on parentheses, braces, functions vs methods), so at least there's already some consensus among your sources. I seem to recall the P5EE guide having a whole section on object-orientation though, conspicuously absent in the notes available now. I have found that to be very helpful before; hopefully it will reappear at some point. But I have some suggestions for managing development in a large OO project:

    • Adopt a standard terminology for describing things not enforced by perl itself, i.e.: public/private/protected variables and methods; static vs instance methods; container classes like arrays of user-defined objects. I've found it helpful to borrow terms from Java/C++ to describe how a method is supposed to operate. POD can contain anything, so public static void foobar(String str) is perfectly legit, even if perl and pod2html don't have a clue as to the meaning.

    • Define a standard model of exception handling. Personally I like the C++/Java style of try/catch/finally as opposed to eval/die, and so I lean toward using modules like Error or Exception, but what matters is that everyone can count on code choking in the same way.

    • Decide upon a standard form of constructor. On my project, much to my frustration, I've found in a number of cases that modules previously written (yes, some were mine) were not written to support full inheritance with respect to initialization of state. While inheritance of methods is very easy to attain, it takes more careful planning to ensure that child classes will be able to utilize the superclass's initialization code. Whether you want to follow Java's model where each constructor's first act is to call super() all the way up to java.lang.Object or to try an approach like separating instantiation from initialization (my favored method nowadays), what matters is that you avoid the situation where a programmer wanting to subclass an existing module needs to read the code for the proposed superclass. And to do this requires a standard format for constructors. (See inheritance: constructors)

    • Create a module for argument checking that all programmers can use when validating data coming into a method. This keeps a major source of redundant code in one place, and ensures that you know something about the safety of your code across the whole project. It also means that you can simply turn off argument checking if you want to for speed.

    Good luck, fever

      Create a module for argument checking that all programmers can use when validating data coming into a method. This keeps a major source of redundant code in one place, and ensures that you know something about the safety of your code across the whole project. It also means that you can simply turn off argument checking if you want to for speed.

      I, the omnipresent Anonymous Monk, wholeheartedly second this advice. It saves a lot of work and results in far simpler, more flexible software. It took me far too long to start doing this myself. Good stuff.

        Even better, get one off CPAN, like Params::Validate (which I wrote) or Getargs::Long.
Re: Re: Perl Style Guides for Large Projects
by da (Friar) on Nov 01, 2002 at 18:17 UTC
    Thanks for the reference to p5ee. I've emailed their list to find out what their current status is; it looks like they've gone through some changes in focus recently. But it still looks useful for my talk. For what it is worth, I found the style guide within their code download and it is in their CVS tree. But they really should fix that link. :-)

    Update: The URL to their style guide is fixed.

    ___ -DA $_='daniel@coder.com 519-575-3733 /Prescient Code Solutions/ coder.c +om ';s/-/ /g;s/([.@])/ $1/g;@y=(42*1476312054+7*3,14120504e4,-42*330261-3 +3, 42*5436+3,42*2886+10,42*434987+5);s/(.)/ord(uc($1))/ge;for(@x=split/32 +/; @y; map{print chr} split /(..)/, shift(@x) + shift(@y)) {perlmonk.da.r +u}