note doom <P>Almost any set of coding standards is better than none, and were I working for a boss that was a "Best Practices" fanatic, I would be overjoyed at having such an enlightened employer. <P> That said, despite that fact that I like the book "Perl Best Practices" quite a bit (I've read it around three times now), once I've added up my questions and disagreements on each point, I personally would only recommend following around two-thirds of Damien's recommendations. <P> Off the top of my head, a few disagreements: <UL> <LI>He recommends his own Class::Std for doing inside-out objects, but it has problems with threads. Quinn Weaver of SF-perlmongers has been pushing Object::InsideOut, and I would probably try that first. <LI>He seems to like source filters, and I definitely don't (I don't think that any one who uses the perl debugger would enjoy putting up with source filters). So every time he recommends a module, I need to check to see how it was implemented. <LI>I like interspersed pod style (where each method has an "=item" accompanying the "sub" that explains how to use the method) -- it has it's problems, but overall I think it reduces the comments you need to write for a sub by supplying some verbal info in the form of documentation. I think his arguments for segregated pod boil down to personal taste (when he looks in a code file he wants to see code). <LI>I have a number of differences on small stylistic issues, though the only one that comes to mind is that I think "unless" improves readability enough that you should use it instead of "if not", even though it's true that "if not" can sometimes make later edits eaisier. </UL> <P> 655882 655882