Hmm.. Interesting! I like these rules, but not all of them. I guess, I am going to compile my own list. (Edit: A little clarification here. These are not my rules. They are rules written by others, and I adopted them (some of them). They are my rules in the sense that I shall use them. So, here is the list. I copied all these rules from this thread (mainly mentioned by moritz, and Erix mentioned Abigail's guidelines). I copied all of those, and then I deleted what I didn't like and tweaked some of the existing ones.
Programs should have an exit value of 0 when running succesfully, and a non-0 exit value when there's a failure.
Place a semicolon after every statement.
Never place two statements on the same line
(my edit:) unless they are somehow related or part of the same logic process. For example:
$R >= 0 or $R = 0; $R <= 255 or $R = 255;
$G >= 0 or $G = 0; $G <= 255 or $G = 255;
$B >= 0 or $B = 0; $B <= 255 or $B = 255;
3) Always start your elsif or else block on a new line.
(my edit:) unless the last elsif block contains a very short line and the
next else {} block also contains a very short line. In that case, it's ok. For example:
elsif ($Color & 255) { $RGB++; } else { $GRAY++; }
(my edit:) Use CamelCase whenever possible. For more important variables,
use all uppercase letters. Avoid using constants as much as possible, but if you must, use all caps and very short names for constants (4-5 letters).
In classes, prefix subroutines with an underscore to identify an "internal use only" method.
Use unless and until as little as possible.
Don't do stupid things
Think about what you write
Be consistent
Correctness, simplicity and clarity come first.
Avoid unnecessary cleverness. If you must rely on cleverness, encapsulate and comment it.
Avoid duplication (DRY).
Coupling and Cohesion. Systems should be designed as a set of cohesive modules as loosely coupled as is reasonably feasible.
Data hiding. Minimize the exposure of implementation details.
Minimize the scope of variables, pragmas, etc..
Establish a rational error handling policy and follow it strictly.
Interfaces matter. Design interfaces that are: consistent; easy to use correctly; hard to use incorrectly; easy to read, maintain and extend; clearly documented; appropriate to your audience. Be sufficient, not complete; it is easier to add a new feature than to remove a mis-feature.
Write components that are testable in isolation.
Use descriptive, explanatory, consistent and regular names.
Don't optimize prematurely. Benchmark before you optimize. Comment why you are optimizing.
Agree upon a coherent layout style and automate it.
Always use warnings and strict. Adopt a policy of zero tolerance for warnings and errors.
Programs SHOULD support the --help and --version options.
Code SHOULD have an exhaustive regression test suite. -- This sounds cool, but I have no idea what it means.
Subroutines in standalone modules SHOULD perform argument checking and MUST NOT assume valid arguments are passed.
POD SHOULD not be interleaved with the code, and is not an alternative for comments.
Comments, POD and variable names MUST use English.
(my edit:) Lines should not exceed 70 characters unless absolutely necessary.
Align code vertically.
(my edit:) I don't like to use TABS. I always use two spaces to indent code.
(my edit:) Avoid using goto and eval() like a plague.
(my edit:) It's okay to break any rule occasionally if you must, if you have a good reason for it.