Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re: Perl Programming guidlines/rules

by Abigail-II (Bishop)
on Nov 21, 2002 at 13:05 UTC ( #214759=note: print w/replies, xml ) Need Help??

in reply to Perl Programming guidelines/rules

1. Use strict and use warnings

I'd be very wary about a 32 point coding standard that puts two totally unrelated things in the first item. It's like saying "use apples and red paint". Which strict are you referring to? We have three, making 8 combinations. Furthermore, there are situations the obvious and clearest way to do something is prevented by some form of strictness. Or that it will issue a warning. Coding standards that mandate the use of strictness and/or warnings should also allow you to turn them off when appropriate.

2. use HTML::Template not HERE documents

Huh? Since when is HTML::Template always an alternative for HERE documents? I typically use HERE documents to write SQL statements - is HTML::Template a logical alternative for that?

5. OO always to be used where possible

I can understand that rule. But it doesn't make sense as a rule when Perl is the used language. Java, Python, Ruby, ok. But Perl? Where OO is slapped on to the language, and in a bad way?

6. Pass by reference

This is the default by Perl, and kind of hard to bypass. Or do you mean that you can't allow literals as subroutine arguments?

9. Do not reinvent wheel always check CPAN

But CPAN contains a lot of bad code. Often, reinventing the wheel is faster than checking the quality of a CPAN module. Besides, who are you going to blame if the CPAN module contains a fatal bug?

13. Always indent logic

I do not know what you mean by this.

14. Any reused code block above 5 lines must become a sub routine

Bad rule. Reuse is often good, but sometimes copy-and-paste is preferred. Reuse code if you expect the code always to be the same. But use copy-and-paste if you want the flexibility that the copied code later will do something else.

15. Always retrieve database rows into hash reference not arrays


17. Assign CGI parameters to hashes


18. Version history at bottom of file

That's all you have to say about version history? No standardization on a version control mechanism?

21. Constructors must only create objects

But no rules on object initializators?

24. use my not local

Really? I can't local punctuation variables, aggregate elements, tied variables, or file handles?

27. Use verbs for subroutines, use nouns for variables, be descriptive and consistent.

That's very surprising! You wanted OO, didn't you? That means you will have lots and lots of subroutines that will return something, and not "do" something. How am I supposed to name a method that returns the creation date? I'd prefer "creation_date", a noun. But what verb ought to be used?

28. Do not use $_

Not use $_?????? Are you talking about the same Perl language as I do?

29. Do no use goto

Really? Does that mean I can't use AUTOLOAD that makes an accessor on the fly and then uses magic goto to go to it? Can I use a CPAN module that uses goto?

30. Initialise variables

That means that autovivifying file handles are forbidden? That I cannot do my @array; push @array => 3;, but that I have to do my @array = (); push @array => 3;?

31. Error handling done using Begin blocks at CGI level. All dies are logged

That doesn't make any sense to me. If I know at compile that an error will happen, wouldn't it be better to fix my code? And how am I supposed to handle errors that occur at run time? Eval code with a begin block that deals with the error?

32. Where code returns a result it should do so or die with a meaningful error and $!

I've no idea what you mean by this.

To me, this list looks bad. Not much thought has been put in it, and important guidelines are missing. Too many buzzwords.

What about the language used for comments and variable names? Can that be in Chinese combined with Greek? How should objects be implemented? This is a vital guideline in OO-Perl, otherwise inheritance will fail. Is there a require bracing style? Indent size? Variable naming convention? How do you pass parameters to function? Positional parameters? Named parameters? What are you API/object interface guidelines?


Replies are listed 'Best First'.
Re: Re: Perl Programming guidlines/rules
by cfreak (Chaplain) on Nov 22, 2002 at 22:15 UTC

    While I agree with some of your points I don't believe hakkr was refering to code that is within other modules. (Like the Autoload example you gave) and I believe he means that HTML::Template should be used for HTML documents instead of adding tons of lines to a CGI program for the HTML. As one who has spent a lot of time using both, it makes lots of sense, separating HTML from the core CGI program make the code easier to understand and allows for designers that don't know a lick of Perl to play with the template files and add their prettyness to them.

    Even though I agree I think that you are nitpicking at his idea rather than offering objective criticism. You try to refute some of his points without actually understanding them. Such as 32. Where code returns a result it should do so or die with a meaningful error and $!
    I think that clearly states that rather than:

    open(FILE,"$filename") or die $!;
    He's saying that his programmers should put:
    open(FILE,"$filename") or die "The file $filename couldn't be opened: +$!";

    This make tons of sense! In a large program its helpful to see "foo.txt couldn't be opened: no such file or directory" rather than "no such file or directory", especially if you are opening more than one file.

    My major complaint with your comment is your feeling about CPAN, he didn't say to never reinvent wheels, he said check CPAN first. Which is a very good idea. Frankly I'm not sure what CPAN you use, bad code usually gets marked as such and there are places to put test results if the code is failing. I use a lot of CPAN modules and normally the only reason one didn't work was because I didn't install it correctly. CPAN saves me tons of time.

    I'm sorry but I had to mod you down for this comment. The tone is more "I don't do it this way, neither should you" which to me goes against the idea of Perl that you can do it any way you want to. I don't blame people for wanting programmers to follow a standard.


    Lobster Aliens Are attacking the world!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://214759]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2018-05-27 05:54 GMT
Find Nodes?
    Voting Booth?