Best practices · Stacks and tools
Code Review Best Practices
Opens with creditsA 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.
Written by Tauseef Fayyaz7 chapters, 31 practicesAbout 24 min22 quiz questionsReviewed 13 October 2026What you will learn
7 chapters · about 24 min
1The standard for approving a changeBefore 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.4 practices · 3 min
- 1Approve a change once it clearly improves the code, even if it is not perfect
- 2Settle arguments with facts, the style guide and engineering principles
- 3Reject changes the codebase does not need, even when the code is good
- 4Teach through reviews, but mark lessons as optional
4 in this chapterOpen this chapter2What to look for in a reviewA 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.6 practices · 5 min
- 1Start with design: does this change belong here and fit the system?
- 2Check that the change does what the author intended, including edge cases
- 3Push back on code that is more complex than it needs to be
- 4Review the tests and ask whether they would fail if the code broke
- 5Check names, comments and documentation explain the code to the next reader
- 6Read every line you were asked to review, in the context of the whole file
6 in this chapterOpen this chapter- Review speedSlow 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 practices · 3 minOpens with credits
- Writing review commentsHow 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 practices · 4 minOpens with credits
- Handling pushback and disagreementAuthors 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.4 practices · 3 minOpens with credits
- Making your changes easy to reviewMost review pain starts before the reviewer opens the change. This chapter covers small changes, separating refactors, descriptions and reviewing your own diff first.4 practices · 3 minOpens with credits
- Team habits and toolingA few team level decisions make every individual review easier: automating style, routing reviews to the right people and taking extra care with risky changes.4 practices · 3 minOpens with credits
About this guide
These code review best practices are for anyone who reviews code or sends it for review, whether on GitHub, GitLab, Gerrit or any other tool. They are built mainly on Google's published engineering practices for code review, one of the most detailed public guides on the topic, plus GitHub's documentation on code owners.
Code review is how a team keeps a codebase healthy while many people change it. A good review catches bugs and design problems before they reach users, spreads knowledge of the code across the team, and keeps the style consistent. A bad review process does the opposite: changes wait for days, comments feel personal, reviewers argue about taste, and authors learn to send huge changes because each review costs so much.
The first chapters are for reviewers: the standard for approving a change, what to look for, how quickly to respond and how to write comments. Then come handling disagreement, the author's side of the process, and the team habits and tools that make reviews smoother.
If you are new to a team, reviewing is also one of the fastest ways to learn the codebase. Reading other people's changes carefully, and asking good questions about them, teaches you how the system fits together.
Common questions
How long should a code review take?
Google's guide says one business day is the maximum time to respond to a review request, and that a typical change should get all its rounds of review within a day. Speed of each response matters more than total time. Keeping changes around 100 lines makes this realistic.
What should I look for in a code review?
Start with the design and whether the change belongs in the codebase. Then check that it works, including edge cases and concurrency, that it is no more complex than needed, and that the tests would fail if the code broke. Finally check naming, comments that explain why, style and documentation.
How big should a pull request be?
Google's guide says about 100 lines is usually reasonable and about 1,000 lines is usually too large, with file spread mattering too. More important than the number is that the change does one self contained thing, includes its tests and keeps the build working.
What does Nit mean in code review?
A Nit: comment marks a minor issue, a small polish point that will not significantly affect the code. Labels like Nit:, Optional: and FYI: show the author which comments are required and which they can skip.
Should I approve a pull request that is not perfect?
Yes, if it clearly improves the overall health of the code. Google's guide says reviewers should favour approving once a change definitely improves code health, even if it is not perfect, and mark remaining polish as optional. Never approve a change that makes the code worse, except in a real emergency.
How do I give code review feedback without sounding harsh?
Comment on the code rather than the person, explain why you are asking for a change, and phrase concerns as observations or questions. Label optional points so they do not read as demands, and mention what was done well. Most upset in review comes from wording, not from high standards.
Sources (8)
Checked against these, last on 13 October 2026.
- The Standard of Code Review, Google Engineering Practicesgoogle.github.io/eng-practices/review/reviewer/standard.html
- What to look for in a code review, Google Engineering Practicesgoogle.github.io/eng-practices/review/reviewer/looking-for.html
- Speed of Code Reviews, Google Engineering Practicesgoogle.github.io/eng-practices/review/reviewer/speed.html
- How to write code review comments, Google Engineering Practicesgoogle.github.io/eng-practices/review/reviewer/comments.html
- Handling pushback in code reviews, Google Engineering Practicesgoogle.github.io/eng-practices/review/reviewer/pushback.html
- Small CLs, Google Engineering Practicesgoogle.github.io/eng-practices/review/developer/small-cls.html
- Best practices for pull requests, GitHub Docsdocs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/best-practices-for-pull-requests
- About code owners, GitHub Docsdocs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Git Best Practices for DevelopersGit best practices for everyday work: clear commits, clean branches and pull requests, rebase vs merge, safe force pushes, secrets, signing and recovering mistakes.
- Technical Writing Best Practices for EngineersTechnical writing best practices for developers: write for your audience, clear sentences, scannable structure, design docs, READMEs and docs, PR descriptions, async updates and blog posts.
- CI/CD Best PracticesBuild pipelines that are fast, trustworthy and safe to deploy from: trunk-based flow, fast tests, locked-down workflows, signed artifacts, canaries and DORA metrics.
Checklists
See allProject structures
See all- VS Code extension project structureA TypeScript extension for Visual Studio Code, built from the official Yeoman generator with esbuild bundling. The example, TODO Lens, finds TODO comments and shows them in a tree view, with commands, settings and editor decorations. The tree grows from the generator's Hello World into commands, providers and editor-free core logic, then tests on three operating systems, publishing to the Marketplace and Open VSX, and a webview with a strict security policy. For students who use VS Code every day and want to build a tool other developers install.
- Python package and CLI project structureA command line tool published to PyPI, laid out the way the Python Packaging User Guide and uv recommend: a src layout, one pyproject.toml for metadata and every tool, a thin Typer CLI over plain, testable modules, and releases uploaded by GitHub Actions with trusted publishing. The example is mdlinks, a tool that finds broken links in Markdown files. For students who have written Python scripts and want to ship one that strangers can
pip install. - TypeScript npm library project structureA small, typed npm package (a retry helper) built the way modern libraries ship in 2026: TypeScript source in
src, bundled by tsdown intodistwith type declarations and anexportsmap, tested with Vitest, checked with publint and Are the Types Wrong, versioned with Changesets and published from CI with npm provenance. For students who want to publish their first package, and for anyone whose package works locally but breaks for users.
Career questions
See all- How do I learn Git and GitHub properly instead of just copying commands?Learn the model first: commits are snapshots, branches are pointers, and remotes are copies. Then use Git daily on your own projects, practise a team workflow with branches and pull requests, and break things on purpose, such as merge conflicts, so you learn to recover calmly.
- How do I build a developer portfolio as a beginner with nothing to show?Start with two or three small but complete projects that solve a real problem, each with a clear README, screenshots and a live link or easy run steps. Put them on a simple one-page site or a tidy GitHub profile. Depth and finish matter far more than the number of projects or a fancy design.
- What should I do in the summer after my first year of computer science?Use it to build one real project, get comfortable with Git and a second area of programming, and try one thing outside class such as a hackathon, open source or a small internship. Keep a weekly schedule of 15 to 20 hours and leave room to rest. You do not need to master everything this summer.
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.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com