My Checklist for Code Reviews

The following are the usual steps I try to take when reviewing pull requests. Not all steps are required each time, but this checklist serves as a good reminder and has often helped me and the team catch bugs early.

• Make sure the branch name follows the guidelines set by the team/project/company.
• Verify commits have meaningful names and are separated pragmatically. If commits will be squashed, check the squash commit message
• Check the PR's target branch.
• Read the PR's description and request more information if context is missing.
• Go through the changes once to check for typos in variable names or comments.
• Clone the branch locally.
• Open touched files in the IDE and check for ESLint/Prettier/TypeScript warnings and errors (pre-commit hooks should already catch these, but --no-verify exists). This step should be completely replaced by a proper CI pipeline that has already done these checks when the PR was opened.
• Test the feature locally and report any bugs that are identified.
• Go over the implementation and suggest improvements.
• If during the review, code "around" the implementation can be improved, decide with the author whether a separate engineering task should be created or if it can be part of the current PR. Usually opt for the first option.