Concise Code Review Checklist

concise-code-review-checklist.md

• The implementation fulfills the desired requirement.
  Details

  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.
  Details

  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.
  Details

  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.
  Details

  SOLID principles are used efficiently, making the code reusable and scalable.
• The code is readable.
  Details

  The code is readable and comprehensive. Comments are clear, useful, and explain why instead of what.
• The code has appropriate tests.
  Details

  Tests should be added, as appropriate, in the same changelist as the code. Tests should be correct, sensible, and useful.
• Documentation has been updated.
  Details

  Devs should update associated documentation. If code is deleted or deprecated, then the documentation should also be deleted.
• Web accessibility standards are added.
  Details

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

- [ ] 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>