Difference between revisions of "Code review"

From Software Heritage Wiki
Jump to: navigation, search
m (Guidelines)
m (Good reads)
Line 19: Line 19:
  
 
* '''[https://medium.com/palantir/code-review-best-practices-19e02780015f Best practices]''' (Palantir) ← comprehensive and recommended read, especially if you're short on time
 
* '''[https://medium.com/palantir/code-review-best-practices-19e02780015f Best practices]''' (Palantir) ← comprehensive and recommended read, especially if you're short on time
* [https://github.com/thoughtbot/guides/tree/master/code-review Best practices]''' (Thoughtbot)
+
* [https://github.com/thoughtbot/guides/tree/master/code-review Best practices] (Thoughtbot)
 
* [https://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines Review checklist] (Code Project)
 
* [https://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines Review checklist] (Code Project)
 
* [https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs/ Motivation: team culture] (Google & FullStory)
 
* [https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs/ Motivation: team culture] (Google & FullStory)

Revision as of 12:59, 12 October 2018

This page documents code review practices used for Software Heritage development.

WORK IN PROGRESS page

Guidelines

  1. Code reviews (CRs) are strongly recommended for any non-trivial code change, but not mandatory (nor enforced at the VCS level).
  2. The CR workflow is implemented using Phabricator/Differential.
  3. 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).
  4. Review anything you want: no matter the suggested reviewer(s), feel free to review any outstanding CR.
  5. One LGTM is enough: feel free to approve any outstanding CR.
  6. Review every day: CRs should be timely as fellow developers will wait for them. To make CRs team-sustainable each developer should allocate a fixed minimum amount of time for doing CR 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:

See also