2.1 KiB
Note This code review checklist is intended to serve as a starting point for the author and reviewer, although it may not be appropriate for all types of changes (e.g. fixing a spelling typo in documentation). For more in-depth discussion of how we think about code review, please see Code Review Guidelines.
Author
- Self-review your own code in GitHub's web interface1
- Add automated tests as appropriate
- Check the code coverage2 report for the automated tests
- Update documentation as appropriate (e.g README.md, etc.)
- Pull in the latest changes from the main branch and squash your commits before assigning a reviewer3
Reviewer
- Check the code with the Code Review Guidelines checklist
- Perform an ad hoc review4
- Review the automated tests
- Review the documentation, README.md, etc. as appropriate
-
Code often looks different when reviewing the diff in a browser, making it easier to spot potential bugs. ↩︎
-
While we are not looking for perfect coverage, the tool can point out potential cases that have been missed. Code coverage can be generated with:
./gradlew check. ↩︎ -
Having your code up to date and squashed will make it easier for others to review. Use best judgement when squashing commits, as some changes (such as refactoring) might be easier to review as a separate commit. ↩︎
-
In addition to a first pass using the code review guidelines, do a second pass using your best judgement and experience which may identify additional questions or comments. Research shows that code review is most effective when done in multiple passes, where reviewers look for different things through each pass. ↩︎