Following the checklist saves the reviewers’ time and gets your PR reviewed faster.

Self Review

Have you reviewed every line of your changes by yourself?

Test

Have you added enough test cases to cover the new feature or bug fix?
Also, add comments to describe your test cases.

Naming

Do function names keep consistent with its behavior?
Is it easy to infer the function’s behavior by its name?

Comment

Is there any code that confuses the reviewer?
Add comments on them! You’ll be asked to do so anyway.
Make sure there is no syntax or spelling error in your comments.
Some online syntax checking tools like Grammarly may be helpful.

Refactor

Is there any way to refactor the code to make it more readable?
If the refactoring touches a lot of existing code, send another PR to do it.

Single Purpose

Make sure the PR does only one thing and nothing else.

Diff Size

Make sure the diff size is no more than 500, split it into small PRs if it is too large.

Code Review Guide

Things to do before you start reviewing the PR

  • Make sure you are familiar with the packages the PR modifies.

  • Make sure you have enough continuous time to review the PR, use 300 LOC per hour to estimate.

  • Make sure you can follow the updates of the PR in the next few work days.

  • Read the description of the PR, if it’s not easy to understand, ask the coder to improve it.

  • For a bug fix PR, if there is no test case, ask the coder to add tests.

  • For a performance PR, if no benchmark result is provided, ask the coder to add a benchmark result.

Things to check during the review process

  • Am I able to understand the purpose of each unit test?

  • Do unit tests actually test that the code is performing the intended functionality?

  • Do unit tests cover all the important code blocks and specially handled errors?

  • Could procedure tests be rewritten to table driven tests?

  • Is the code written following the style guide?

  • Is the same code duplicated more than twice?

  • Do comments exist and describe the intent of the code?

  • Are hacks, workarounds and temporary fixes commented?

  • Does this function do more than the name suggests?

  • Can this function’s behavior be inferred by its name?

  • Do tests exist and are they comprehensive?

  • Do unit tests cover all the important code branches?

  • Could the test code be extracted into a table-driven test?

Things to keep in mind when you are writing a review comment

  • Be kind to the coder, not to the code.

  • Ask questions rather than make statements.

  • Treat people who know less than you with respect, deference, and patience.

  • Remember to praise when the code quality exceeds your expectation.

  • It isn’t necessarily wrong if the coder’s solution is different than yours.

  • Refer to the code style document when necessary.

Things to remember after you submitted the review comment

  • Checkout Github notification regularly to keep track of the updates of the PR.

  • When the PR has been updated, start another round of review or give it a LGTM.