Code review
Revision as of 13:51, 12 October 2018 by StefanoZacchiroli (talk | contribs) (→See also: add coding guidelines link)
This page documents code review practices used for Software Heritage development.
Guidelines
Please adhere to the following guidelines to perform and obtain code reviews (CRs) in the context of Software Heritage development:
- CRs are strongly recommended for any non-trivial code change, but not mandatory (nor enforced at the VCS level).
- The CR workflow is implemented using Phabricator/Differential.
- Explicitly suggest reviewer(s) when submitting new CR requests: either the most knowledgeable person(s) for the target code or the general reviewers group (which is the default).
- Review anything you want: no matter the suggested reviewer(s), feel free to review any outstanding CR.
- One LGTM is enough: feel free to approve any outstanding CR.
- Review every day: CRs should be timely as fellow developers will wait for them. To make CRs sustainable each developer should strive to dedicate a fixed minimum amount of CR time every (work) day.
For more detailed suggestions (and much more) on the motivational and practical aspects of code reviews see Good reads below.
Good reads
Good reads on various angles of code review:
- Best practices (Palantir) ← comprehensive and recommended read, especially if you're short on time
- Best practices (Thoughtbot)
- Best practices (Smart Bear)
- Review checklist (Code Project)
- Motivation: code quality (Coding Horror)
- Motivation: team culture (Google & FullStory)
- Motivation: humanizing peer reviews (Wiegers)