Code Review

When someone submits a pull request to the project it is reviewed by a minimum of two developers.

What follows is the guidance developers should following when reviewing code.

Checklist

When performing a review the following things should be considered:

To make it easier for us all to work together we need to ensure that we are working to a common set of standards, and that the way we are coding is as easy to follow as possible.

  1. The projects coding standards are being met.

  2. The code should be easy to understand, comments can and should be used to assist with this.

  3. PHP docs have been updated and help with the understanding of the code

  1. The commits are split logically (i.e. a single short line should be able to summarise the change in each commit)

  2. Each commit message starts with a ticket number followed by a short 1 line summary of the change

  3. Where changes are complicated there is a blank line followed by longer description

  1. PHPdocs and comments are useful (Make sure that value is added, i.e. the function name is not just repeated)

  2. Significant changes have had the appropriate specifications and developer documentation updated

  3. Commit messages help explain changes

  1. Where possible output is not mixed in with programme logic (this makes things easier to maintain) some projects will make this easier than others.

  2. Output conforms to the project HTML standards.

  3. Inline styles should not be used (external stylesheet files are better for maintainability)

  1. Output should be in a form that can be localised

  2. Language used will be understandable by end users