At 09:43 AM 3/23/2002 +0100, Bas A.Schulte wrote: .... >Some blurbs from vision/mission: > >> mission of the P5EE project is to promote the development, deployment, >> and acceptance of Enterprise Systems written in Perl > ^^^^^^^^^^^^^^^^^^^^^^^^ > >> IT managers have confidence in hiring enterprise architects > ^^^^^^^^ > >These being some of the goals of p5ee, I wonder how the current coding >guidelines/style guide came to be.
If you want to know how they came to be, take a look back in the discussion archive. http://archive.develooper.com/p5ee%40perl.org/ See the thread "Needing some standards to start with" <01-Nov-2001> starting with this message. http://archive.develooper.com/p5ee%40perl.org/msg00124.html See the thread "P5EE Style Guide" <02-Nov-2001> starting with this message. http://archive.develooper.com/p5ee%40perl.org/msg00145.html See the resulting P5EE Style Guide. http://www.officevision.com/pub/p5ee/software/htdocs/P5EEx/Blue/perlstyle.html You will see it is consistent with (and mainly an extension of and elaboration of) the Perl 5 style guide ("man perlstyle") that ships with every version of Perl 5. http://www.perldoc.com/perl5.6.1/pod/perlstyle.html >If you want to see a larger >acceptance in the enterprise world and it's managers it's been my >experience that it helps a *lot* when your code looks like java code. Sorry. That is a different battle that you are going to need to fight. Perl is Perl, and it has its own traditions and conventions. The most important element to winning management approval is not naming tricks, but unbeatable ROI, high developer productivity, and sound design and documentation. The most important thing for this is to have the force of the Perl community behind us (wind in our sails). That is why P5EEx::Blue is trying so hard to interoperate with and harness the strengths of so many of the good efforts that have gone before. >I have had several technical due dilligences taken by "enterprise"-type of >guys and received a lot of credit as they saw that the perl code at our >company really looked like java. The coding guidelines were defined >based on looking long and hard at both Sun's java coding guidelines as >well as guidelines defined within RUP (Rational Unified Process) and >adapted them to the perl world. There are technology bigots in every organization. (It has to be Microsoft. It has to be Java.) >These guidelines led to perl code that was easy to read by anyone with >basic programming experience, even by big hurds of java programmers ;) >None of the line-noise that we are so used to in the perl world. I dare >to say that it's not perl itself that leads to line-noise, it's how perl >is being used which is something you can enforce by good guidelines that >are already accepted in the enterprise world. I think the answer to this is standard coding practices http://www.officevision.com/pub/p5ee/software/htdocs/P5EEx/Blue/perlstyle.html and good documentation generated from the code. http://www.officevision.com/pub/p5ee/software/htdocs/api/ >The highlights in this respect are primarily "StudlyCase" and the use of >"getXXX/setXXX" on attributes: > >my $user = $context->user(); > >or > >$user = $self->{cgi}->remote_user(); ## this is a "get" >$self->{cgi}->remote_user($user); ## a "set" (same name!) get_x()/set_x($x) vs. x()/x($x) methods are a matter of programmer taste. I happen to prefer the former. There are strong traditions in Perl for the latter as well. In my opinion, it's not an issue to lose sleep over. Stephen
