Checklist: Code Review
Review code against the coding guidelines defined by the team.
Relationships
Main Description

This is a general checklist for code reviews. Use this as a starting place for a team's review of their code. 

Check Items
Does the code follow the coding guidelines?
See Artifact: Code Analysis Guidelines for your team's documented guidelines.
Is the code self-documenting?

Readers should be able to understand the code by reading it, and without referring to external documentation. This is separate from being able to understand the design, which might be discernable in the code but will also need the design artifact to fully understand it.

Have all errors detected by code-rule checking and/or runtime error detection tools been addressed?
Are all comments up-to-date?
Are the comments clear and correct?
Are the comments easy to modify if the code changes?
Do the comments focus on explaining "what" and "why" rather than "how"?
The "how" should be clear in the way the code is written.
Are all surprises, exceptional cases, and work-arounds explained in the comments?
Is the purpose of each operation explained in the comments?
Are all the relevant facts about each operation commented?
Does each operation have a name that describes what the operation does?
Don't restrict the team to short names. Use names that are as long as necessary to fully explain what an operation does.
Do the parameters and variables have descriptive names?
Don't restrict the team to short names. Use names that are as long as necessary to fully explain what a parameter does.
Is the normal path through each operation clearly distinguishable from other exceptional paths?
Are any operations or functions too long?

Long operations are difficult to read and understand. Simplify operations by extracting cohesive sections into private operations.

Is loop-nesting minimized?
Deeply nested loops makes code more difficult to understand and maintain.