Things to look for during a code review

What not to do

1. (re)designing the architecture
2. commenting on style alone (unless not adhering to Code Style
3. writing code (only applicable to Group Code Reviews)

Overview

1. Finding bugs
   • NPEs, no privilege checks, etc
2. Create common Coding style

...

1. Does the code make sense?
   • Make an effort to understand what the code is supposed to do before performing a code review.
   • Require the developer to comment as much as necessary to make the code readable.
2. Does the code comply with the accepted Coding Conventions?
3. Does the code comply with the accepted Best Practices?
   • See Conventions
4. Does the code comply with the accepted Comment Conventions?
   • All classes and methods should contain a descriptive JavaDoc comment.
   • All methods should contain brief comments describing unobvious code fragments.
   • All class files should contain a copyright header.
   • All class files should contain class comments, including author name.
   • All methods should contain comments that specify input parameters.
   • All methods should contain a comment that specifies possible return values.
   • Complex algorithms should be thoroughly commented.
   • Comment all variables that are not self-describing.
   • Static variables should describe why they are declared static.
   • Code that has been optimized or modified to "work around" an issue should be thoroughly commented, so as to avoid confusion and re-introduction of bugs.
   • Code that has been "commented out" should be explained or removed.
   • Code that needs to be reworked should have a TODO comment and a clear explanation of what needs to be done.
   • When in doubt, comment.
   • When you've commented too much, keep commenting.
   • When your wrists hurt from commenting too much, take a break ... and then comment more.

...