I've been researching this problem in upgrading our code review course and code review services recently.

The biggest problem with your list is that you have very little that can be objectively tested. A checklist item is useful if everyone could agree that you are following it, but otherwise it simply becomes a way to butt heads in a code review session.

On one of our slides, I bring up the example "you should generally 'use strict'" as a sample bad rule. It's bad because it can't be tested. Is this one of the times that you avoid use strict, or not?

I also have problems with some of your specific rules. For example, "Do not use $_". That's ludicrous. How will you do a grep or map? Or are you proposing coding everything in babybaby Perl?

A reasonable standard for presumption of the skill level of your maintenance programmer is:

• Has read Learning Perl
• Has read all the applicable tutorial series in the core docs
• Knows how to type "perldoc Module::Name"

Anything beyond that should be documented if used, giving a literature reference if needed. Yes, this even goes for the Schwartzian Transform, since that's not in a tutorial doc or Learning Perl, only a FAQ item.

But the biggest point I hope you're seeing is that you should write native Perl when you are writing Perl. Don't constrain Perl to just the parts that are C-like or Shell-like. You miss the point of programming in Perl.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.