note djantzen 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: <ul> <li> Adopt a standard terminology for describing things not enforced by <code>perl</code> 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 <code>public static void foobar(String str)</code> is perfectly legit, even if <code>perl</code> and <code>pod2html</code> don't have a clue as to the meaning. <li> 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 <a href="http://search.cpan.org/author/BIRNEY/bioperl-1.0.2/examples/exceptions/Error.pm"> Error</a> or <a href="http://search.cpan.org/author/PJORDAN/Exception-1.4/Exception.pm"> Exception</a>, but what matters is that everyone can count on code choking in the same way. <li> 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 <code>super()</code> all the way up to <code>java.lang.Object</code> 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 [id://176963]) <li> 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. </ul> Good luck, [fever] 209555 209565