HowToFailACodeReview

I originally wrote this back in 2003, and, as you may guess, it is oriented towards perl programming.

If you want me to reject your code from a code review, here are some steps you can take:

• Don't check your code into some sort of source control system.
• Don't check return values from I/O operators, system calls and the like.
• Do not return proper exit status from your program.
• Don't localize variables to the closest scope possible.
• Create redundant variables.
• Don't indent your code, or don't indent consistently.
• Don't format your code to 80 columns
• Don't comment.
• Don't include expected input near complicated regular expressions
• Don't document script with POD.
• Don't use existing perl libraries to do common operations.
• Use @EXPORT instead of @EXPORT_OK in your modules.
• Don't use "strict".
• Don't have a way of enabling debugging output.
• Don't have an else on an elsif chain.
• Don't make code portable between Unix and NT: use backslashes, hardwire drive letters, &c.
• Don't include any of the following in your error messages: The name of the program or module, the name of the file/dir/program being operated on, the contents of $!, $@ or $? (as appropriate) or what was being done when the error occured.
• Don't follow the maxim: "be strict in what you emit, and liberal in what you accept".
• Don't use white space, or line up columns to make code more readable.
• Don't use standard libraries for parsing command line options.
• Use arcane constructs like variable indirection
• Don't write a test case.

See also: ProgrammingStyle and ErrorMessages