I've run across some formatting guidelines, most of which are competent and uncontroversial. But that's the easy stuff. More interesting items include:
1) Modularizing code for OO. Damian's book is useful but unnecessarily esoteric once you get past the basics. A lot of Perl OO discussion seems to center on secondary things such as closures rather than the pros and cons of different architectural approaches. I continually weigh where to put handy reusable routines I develop in the course of project, how to get globalish data structures into non-class libraries, and other real-world questions. I'm sure there are lots of good OO books, but it would be nice to see one with the examples in Perl instead of Java or C++. 2) The extent to which perlish syntax is to be celebrated/tolerated. This is a moving target, since the more experience you get with Perl the more tolerant you are of line noise. But I find that too much Perl code is unreadable to people other than the programmer, and is not optimal for projects that might someday bring on new or replacement programmers (which is pretty much every serious project). You cite CPAN modules as a place to find examples of good style; my experience is that many CPAN modules are poorly written, almost devoid of comments, hard-wired to assume Unix, etc. One wonderful example of CPAN module idiocy is that many of the modules 'die' on errors rather than trapping and returning on them. How useful is that to a CGI programmer, e.g.? TMTOWTDI, sure, but some things are just plain wrong (and I'm sure John Ashcroft would agree with that). 3) Continuing with the last thought, it seems that the CPAN module guidelines I run across occasionally are more concerned with how to write POD docs than with how to make modules generic and bullet-proof. It would be nice to see a more thoughtful set of recommendations, such as: don't 'die', use comments thusly, show off less and make the code readable, describe the data structures being manipulated inside objects, etc. OK, so why don't I do this? I'm tempted... But I don't know if I have enough experience to do it all. I would contribute to any ongoing effort along these lines, if anyone knows of such. -----Original Message----- From: John Saylor [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 10:20 AM To: Mark Aisenberg Cc: [EMAIL PROTECTED] Subject: Re: [Boston.pm] question & puzzle Hi ( 02.10.11 09:27 -0400 ) Mark Aisenberg: > A useful albeit unsexy project that would be interesting to take on > would be to come up with a style and best-practices guide to Perl > coding. Does anyone have any links to starting brief, readable > starting > points: guides to Perl formatting, OO structure, etc.? I recall several projects coming and going with this in mind. And there may be books too. But all of this flies in the face of one of the greatest strengths [and weaknesses] of perl: TMTOWTDI. But I'd look in the cookbook and the camel book for style guidelines. Or just go to CPAN and study the sources! -- .--- ... _______________________________________________ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
