How Small Should Your Pull Request Be? The 100-Line Test

The Question

How small should your pull request actually be? Not in theory, but in practice. Google's own data from a study of over 9 million code reviews (Modern Code Review: A Case Study at Google, ICSE-SEIP '18) shows the median change size is about 24 lines. Twenty-four lines. More than 10% of changes modify just one line, and over 35% touch only one file. So when a developer opens a PR with 800 lines of changes, something is off. This article argues that small PRs are not just a nice-to-have; they are the foundation of effective code review. If you're regularly sending PRs over 400 lines, you're making your reviewers worse and your codebase riskier.

Why Small PRs Win

Google's engineering practices are blunt: a 100-line change is usually reasonable, and a 1000-line change is usually too large (Google Engineering Practices - Small CLs). That's a wide range, but the message is clear. Small changes are reviewed more quickly and more thoroughly. They are less likely to introduce bugs, easier to merge, and easier to roll back. When a reviewer can see the whole diff in one screen, they can actually think about the design and logic. When they're scrolling through 50 files, they skim. You don't want your reviewer skimming.

The most important thing to cover in a review is the overall design of the change (Google Engineering Practices - What to look for in a code review). You can't assess design if you're drowning in a sea of unrelated refactors. Small PRs force you to make each change purposeful. They also make the review faster, which matters because speed is crucial: Google says it's even more important for individual responses to come quickly than for the whole review to finish fast (Google Engineering Practices - Speed of Code Reviews). A small PR can get a quick LGTM with comments, and the author can iterate immediately. A giant PR stalls for days.

The 400-Line Ceiling

Google's own guidance suggests keeping PRs under 400 to 500 lines of meaningful change (Google Engineering Practices (code review)). That's a hard ceiling, not a target. If you're at 450 lines, you're probably trying to do too much. But don't just split by line count; split by concern. If you're adding a feature and also refactoring a module, that's two PRs. If you're fixing a bug and updating documentation, that's two PRs. The goal is that each PR has a single purpose.

At Google, fewer than 25% of changes had more than one reviewer, and over 80% of reviews finished in a single iteration of resolving comments (Modern Code Review: A Case Study at Google, ICSE-SEIP '18). That's only possible when the change is small and focused. When a reviewer can understand the entire change in one sitting, they can give meaningful feedback immediately. When they have to context-switch across multiple features, they lose track, and the review drags on.

What About the 1000-Line Exception?

Every rule has exceptions, and large PRs are sometimes unavoidable. A generated file, a mass rename, or a dependency update might legitimately touch thousands of lines. But even then, you can often split the review. For example, a dependency update can be reviewed once for the lockfile change and once for the code adjustments. A rename can be reviewed as a separate PR with no logic changes. The point is to keep the meaningful changes small, even if the raw line count is high.

If you must submit a large PR, be explicit about what you want the reviewer to focus on. Google's 'LGTM with comments' technique is useful here: if you're confident the author will address your comments, approve the PR and leave them (Google Engineering Practices - Speed of Code Reviews). But that only works if the comments are minor. On a 1000-line PR, comments are rarely minor.

How to Split a Large PR

Here's a practical approach. First, identify the core change. What is the smallest logical unit that delivers value? That's your first PR. Then, list the remaining changes: refactors, tests, documentation, and cleanups. Each becomes its own PR. If you have a feature that touches multiple layers, consider splitting by layer: API change, database migration, business logic, and UI. Each layer can be reviewed independently.

Another tactic: use draft PRs for early feedback. GitHub allows draft pull requests, and code owners are not automatically requested for review on drafts (GitHub Docs - About code owners). That lets you open a small PR, get design feedback early, and then expand it. But be careful: if you keep expanding, you'll end up with a monster. Set a rule for yourself: if a PR grows beyond 400 lines, stop and split it.

• Start with the design. Ask for feedback on the approach before writing all the code.
• Split by concern, not by file count. One feature, one PR.
• Use draft PRs for early design reviews.
• Never let a PR exceed 500 lines without a compelling reason.

The Bottom Line

Small PRs are not a bureaucratic constraint; they are a tool for better code review. They make your reviewers more effective, your codebase healthier, and your team faster. Google's data proves it: the median change is 24 lines. If your PR is 400 lines, you're not writing small changes, you're writing a small monolith. Start splitting today.

Quick tip: If you're reviewing a large PR, ask the author to split it. You have the right to say, "This is too big for a meaningful review."

The most important thing to remember: The primary purpose of code review is to ensure the overall code health of the codebase is improving over time (Google Engineering Practices - Standard of Code Review). Small PRs are the most reliable way to achieve that.

Sources

• Google Engineering Practices - Small CLs - https://google.github.io/eng-practices/review/developer/small-cls.html
• Google Engineering Practices - What to look for in a code review - https://google.github.io/eng-practices/review/reviewer/looking-for.html
• Modern Code Review: A Case Study at Google (ICSE-SEIP '18) - https://www.papercache.org/papers/mlsys/system/2026/03/25/modern-code-review-a-case-study-at-google
• Google Engineering Practices - Speed of Code Reviews - https://google.github.io/eng-practices/review/reviewer/speed.html
• Google Engineering Practices (code review) - https://google.github.io/eng-practices/review/