Code Review Best Practices
A practical guide to code review for both sides of the pull request, built on Google's published engineering practices and GitHub's documentation. It covers when to approve, what to look for and in what order, how fast to respond, how to write comments people act on, how to handle pushback, and how authors can make their changes easy to review.
7
Sefism · Oct 2026
31
Sefism · Oct 2026
8
Sefism · Oct 2026
Stacks and tools
Sefism · Oct 2026
Best practices
Web Development
Sefism
23 min read
Intermediate
Free
What this best practices guide is
A practical guide to code review for both sides of the pull request, built on Google's published engineering practices and GitHub's documentation. It covers when to approve, what to look for and in what order, how fast to respond, how to write comments people act on, how to handle pushback, and how authors can make their changes easy to review.
It has 7 chapters and 31 practices, each with why it matters, what to do and what to avoid. For developers who review or send code.
Chapter by chapter
1. The standard for approving a change (4 practices)
Before looking at any code, a reviewer needs to know what bar a change has to clear. This chapter covers the core rule, what counts as a preference, and how to settle style and design arguments.
2. What to look for in a review (6 practices)
A checklist of what matters most, in roughly the order Google's guide gives it: design, functionality, complexity and tests first, then naming, comments, style and documentation.
3. Review speed (4 practices)
Slow reviews slow down the whole team. This chapter covers how fast to respond, how to fit reviews around focused work, and when to approve with comments.
4. Writing review comments (5 practices)
How a comment is written decides whether it is acted on or resented. This chapter covers tone, explaining why, labelling severity and giving the right amount of direction.
5. Handling pushback and disagreement (4 practices)
Authors and reviewers will disagree. This chapter covers when to concede, when to hold firm, why "I will clean it up later" rarely works, and how to escalate without stalling the change.
6. Making your changes easy to review (4 practices)
Most review pain starts before the reviewer opens the change. This chapter covers small changes, separating refactors, descriptions and reviewing your own diff first.
7. Team habits and tooling (4 practices)
A few team level decisions make every individual review easier: automating style, routing reviews to the right people and taking extra care with risky changes.
How it works on Sefism
The guide reads like a short course: a syllabus, then one chapter per page in a focused reader, with a quiz at the end of each chapter for members. The opening chapters are open to everyone. Adding it to your account uses credits, opens every chapter and keeps your progress.
Every claim is checked against the sources listed on the page (8 cited).
Ready to start?
Opens on Sefism in a new tab.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.