
Code Review Guidelines
Docs + Word8 pages
Free
Code reviews slow down when nobody agrees what must be checked, and they go soft when reviewers rubber-stamp a 2,000-line change. This code review guidelines template sets one short standard for pull requests: the principles, what authors check before opening a change, what reviewers check, how comments should read, and how disagreements are settled. Each rule is specific enough to verify.
The sample is for Dovecote Systems, a fictional software team, with a size target of 400 changed lines, a four-hour first review and a security section for risky paths. Replace the principles, targets, checklists and examples with your own team's agreements, and trim anything your build already enforces. Keep the checklist to one page, because a long checklist is skipped.
Click Make a copy in Google Docs, then confirm on the Google page. The copy is saved to your own Google Drive.
Replace the principles and targets with your team's agreed standards, then check each one.
Trim the checklists to items your CI does not already enforce, and add the list to the template.
Name the tie-breaker and the escalation route, and add them to the last page.
Delete the guide page, then share the checklist with the team or present it from Google Docs.
No. Dovecote Systems, its staff, the defect costs, review times, coverage targets and the example comments are fictional sample data. Replace them with your team's own measures before you adopt the checklist.
Under 400 changed lines, and ideally under 200. Larger work should be split into a series of changes that each stand on their own, so reviewers can give each one real attention.
The author and reviewer talk first, then bring in the code owner for the area. If the matter is still open after a day, the tech lead decides and records the reason, so the rule is clear next time.
More Google Docs templatesMore developer workflows templates

Docs + Word8 pages
Free
Docs + Word7 pages
Free
Slides + PowerPoint11 slides
Free