Skip to content

Code Review Checklist

Gavin Halliday edited this page Feb 7, 2017 · 11 revisions

The following is an aide memoire of some of the items that should be checked during code reviews. It should be updated when we discover problems that should have been caught by the code review. It may also serve as a list to check against before a pull request is submitted.

General questions

  • Does the pull request contain tests, or details of how it was tested?

  • What could this change break?

  • What impact does it have on documentation? Is there a JIRA?

  • Has the JIRA been updated to describe the issue, and the solution.

Comprehensibility of the code.

  • Is the code readable? (Indentation, variable names, etc.)

  • Is the code simple? Was this optimization really necessary?

  • Does the patch contain commented out code? If so why?

  • Are the public interfaces and functions commented?

Structure of the code.

  • Could some of the code be commoned up or use existing functions instead?

  • Does it have the right level of encapsulation?

Functionality of the code.

  • Could it leak memory (or other resources), or free memory too early?

  • Are there any dangling references to objects which remain after an object has gone out of scope? (Seems to often happen with StringBuffer.str().)

  • Any access via pointers that could potentially be NULL?

  • Any access to uninitialised variables?

  • Check any const_casts - are they really valid?

  • Is the code thread safe? Unprotected access to shared variables? Deadlock/livelock?

  • Does it correctly handle error conditions including exceptions?

  • Does it correctly handle boundary conditions?

  • Could it introduce any security issues?

Compatibility

  • If fixing a bug, could people be relying on the old behaviour?

  • Do we need to reference this change in the Redbook

  • Have we changed any interfaces that will break existing code? Do any interface versions need to be increased?

  • Is the level of change appropriate for the release being targeted?

Miscellaneous

  • Does it use the accepted format for //MORE comments?

  • Does it introduce any trailing spaces?

  • Is the commit message free of typos?

  • Does the commit message title reference the right Jira ticket?

  • Is it targeting the right branch? Does the target build in the Jira ticket match the target branch?