Skip to main content

Code Review

Effective code reviews are crucial for maintaining a high standard of code quality and ensuring that our project is sustainable in the long run. This document outlines the process that developers should follow when contributing code to the project and when performing code reviews.

Self-Review​

Before you create a pull request, conduct a thorough self-review of your code. This step is essential to ensure that your code meets the project's standards and reduces the time required for the review process. During the self-review, make sure that:

  • Your code adheres to the project's Coding Standards.
  • You have tested your code thoroughly and it behaves as expected.
  • Your changes are well-documented, and any new functionality is clearly explained.

Creating a Pull Request​

When you are ready to submit your code for review, create a pull request on GitHub. Make sure to include a detailed description of the changes you have made and any relevant context that the reviewer should know. If your pull request is related to an issue, reference the issue in the description.

Once you have created the pull request, pay attention to:

  • Checks: Ensure that all automated checks (linters, tests) pass successfully. These checks are in place to maintain code quality and stability.
  • Reviews: Your PR needs to be reviewed and approved by at least one other team member before it can be merged. This ensures that at least two people are familiar with the code changes and agree on the implementation.

Code Review​

As a reviewer, your role is critical in maintaining the quality of the codebase. When reviewing a PR, consider the following:

  • Run the Code: Make sure the code runs as expected. If the PR is linked to an issue, verify that the issue is resolved by these changes.
  • Understand the Changes: Take the time to understand what changes are being made and why. This understanding is crucial for assessing the impact of the changes.
  • Check for Bugs: Look for any potential bugs that may have been introduced or not resolved by the changes.
  • Code Quality: Evaluate the code quality, including readability, maintainability, and adherence to the project's coding standards.
  • Leave Comments: Provide constructive feedback and ask questions through comments on the PR. Your feedback should help guide the contributor towards improving their code.

Assignee Responsibilities​

  • Address Comments: If comments are made on your PR, address them promptly. Make necessary changes to your code based on the feedback.
  • Re-Review Required: After you've made changes based on the comments, request a re-review from the original reviewer(s). This process is repeated until the reviewer approves the PR.

Merging the Pull Request​

Once the PR has been reviewed and approved, it can be merged. When merging, consider the following:

  • Track Follow-Up Tasks: Identify any tasks or improvements suggested during the review that need addressing in future PRs. Create issues for these tasks to ensure they're not overlooked.
  • Note Important Changes: Highlight changes requiring special attention in the next release, such as database migrations. Ensure these are documented or communicated to the relevant team members.
  • Clean Up: Once merged, delete the branch to keep the repository organized (this should be done automatically by GitHub).