Code Review Checklist

A concise version in form of a code review checklist has been compiled for a quick freshen up of all the quality checks teams need to perform to approve code into the codebase. A small guide is also provided on how to integrate the concise checklist in GitHub PR Template.

The implementation fulfills the desired requirement.

The code does the intended while also ensuring that it does not cause side:effects or compromise the system performance and functionality.

The code does not add unnecessary complexity.

The code is neither too simple and long (over:engineering) nor too short and complex for peers. With a complex code, devs are likely to introduce bugs when calling or modifying the code.

The code is style guide compliant.

The style guide of project is followed e.g. linting, formatting, types, and other standards. Any style point differing from the guide should not be combined with other changes, as it makes it hard to see what is being changed.

The code follows agreed design principles.

SOLID principles are used efficiently, making the code reusable and scalable.

The code is readable.

The code is readable and comprehensive. Comments are clear, useful, and explain why instead of what.

The code has appropriate tests.

Tests should be added, as appropriate, in the same changelist as the code. Tests should be correct, sensible, and useful.

Documentation has been updated.

Devs should update associated documentation. If code is deleted or deprecated, then the documentation should also be deleted.

Web accessibility standards are added.

The UI built should support accessibility. (See WCAG checklists)

Integrating checklist as PR Template

In order to integrate the code review checklist into your project as a PR template, follow the below mentioned steps:

• On the main/default branch, create file pull_request_template.md inside the .github folder.
• Copy paste the checklist markdown provided below. Commit the file.
• Once the file is pushed on main/default branch, the PR template will reflect in future PRs.

- [ ] The implementation fulfills the desired requirement.
  <details>
    <summary>Details</summary>
    The code does the intended while also ensuring that it does not cause side-effects or compromise the system performance and functionality.
  </details>
- [ ] The code does not add unnecessary complexity.
  <details>
    <summary>Details</summary>
    The code is neither too simple and long (over-engineering) nor too short and complex for peers. With a complex code, devs are likely to introduce bugs when calling or modifying the code.
  </details>
- [ ] The code is style guide compliant.
  <details>
    <summary>Details</summary>
    The style guide of project is followed e.g. linting, formatting, types, and other standards. Any style point differing from the guide should not be combined with other changes, as it makes it hard to see what is being changed.
  </details>
- [ ] The code follows agreed design principles.
  <details>
    <summary>Details</summary>
    SOLID principles are used efficiently, making the code reusable and scalable.
  </details>
- [ ] The code is readable.
  <details>
    <summary>Details</summary>
    The code is readable and comprehensive. Comments are clear, useful, and explain why instead of what.
  </details>
- [ ] The code has appropriate tests.
  <details>
    <summary>Details</summary>
    Tests should be added, as appropriate, in the same changelist as the code. Tests should be correct, sensible, and useful.
  </details>
- [ ] Documentation has been updated.
  <details>
    <summary>Details</summary>
    Devs should update associated documentation. If code is deleted or deprecated, then the documentation should also be deleted.
  </details>
- [ ] Web accessibility standards are added.
  <details>
    <summary>Details</summary>
    The UI built should support accessibility. (See <a href="https://www.wuhcag.com/wcag-checklist/" target="_blank">WCAG checklists</a>)
  </details>