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

Why?

17. Assign CGI parameters to hashes

Why?

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?

Abigail