Pull Request Size: Impact on Code Quality

Small pull requests lead to better code quality. Here's why:

• PRs under 200 lines get reviewed faster and more thoroughly

• Smaller PRs have fewer bugs and merge quicker

• Large PRs (400+ lines) often get poor reviews and more defects

Key takeaways:

1. Aim for PRs under 200 lines of code

2. Use feature toggles to break up big changes

3. Set up automated size checks in your CI/CD pipeline

4. Track PR size metrics to improve over time

Quick Comparison:

Keep your PRs small and focused for better code quality, faster reviews, and smoother development.

Related video from YouTube

Problems with Big Pull Requests

Big PRs can mess up your development process. Here's why:

They're a Pain to Review

When PRs get too big, reviewers struggle:

• After about an hour, they start missing bugs

• They end up doing surface-level reviews

Cisco found that PRs over 400 lines of code catch fewer bugs.

More Bugs Slip Through

Big PRs are bug magnets:

• Smartbear's study showed PRs over 500 lines catch way fewer defects

• When you're changing stuff all over the place, it's easy to mess up

They Slow Everything Down

Large PRs can put the brakes on your whole team:

• Even a small increase in changed files can DOUBLE the time to merge

• PRs stuck in review hold up other work

Keep your PRs small and focused. As Sal Ferrarello says:

"I've never seen a PR that was too small but I've seen many that were too large."

How PR Size Affects Code Quality

PR size impacts bugs, review quality, and code maintenance. Let's break it down:

Bugs and PR Size

There's a clear link:

• PRs over 400 lines? More bugs.

• 50-line changes? 15% less likely to be reverted than 250-line changes.

Smaller PRs = fewer bugs. Simple as that.

Review Quality

Big PRs are a reviewer's nightmare:

• After 60 minutes, "Focus Fatigue" kicks in. Defects slip through.

• PRs over 400 lines? Often zero comments. Not good.

Want sharp reviews? Keep PRs under 400 lines.

Code Maintenance

Large PRs can mess up your codebase:

• Harder to understand changes

• More files touched = more complexity

• More files = longer merge times (up to 2x)

Keep your code clean with small, focused PRs.

"The fastest PRs are those that change the fewest number of files, indicating that high-velocity engineering organizations should architect their systems to minimize file touch points in each PR."

Bottom line? Smaller PRs lead to better code quality, easier reviews, and smoother maintenance.

Ways to Improve Pull Request Size

Want better code and faster reviews? Focus on pull request (PR) size. Here's how:

Set Size Guidelines

Pick a max PR size and stick to it:

• Lines of code: Many teams cap at 400

• File count: Keep it under 10

Some teams prefer logical units over numbers. Just be consistent.

Add Size Checks to CI/CD

Let machines do the work:

• Use GitHub Actions or GitLab CI

• Set up alerts for big PRs

• Block merges for oversized PRs

This keeps everyone in check, no questions asked.

Encourage Smaller, Regular Commits

Build good habits:

• Use draft PRs for early feedback

• Split big changes with feature toggles

• Keep refactoring separate from new features

"Small PRs start long before the work starts. The size of a pull request can be influenced long before the PR is opened." - Artsy Engineering

Smaller PRs = better reviews and fewer bugs. It's all about finding that sweet spot.

Stick to these tips, and you'll see your code quality soar.

How to Break Down Big Changes

Breaking big changes into smaller parts improves code quality and review efficiency. Here's how:

Use Feature Toggles

Feature toggles help manage unfinished features and staged releases. They:

• Let you deploy without showing new code to users

• Allow testing before public release

• Enable quick incident resolution

A game dev team used toggles to overhaul their Spline Reticulation algorithm without messing up the main code.

Split Refactoring from New Features

Keep cleanup separate from new features. This:

• Narrows the scope of each change

• Focuses reviews

• Cuts down on potential bugs

Make separate PRs for refactoring and new features. It helps reviewers get the context faster.

Try Stacked PRs for Complex Work

For complex, dependent changes, use stacked pull requests. This approach:

• Breaks big changes into reviewable chunks

• Makes managing related changes easier

• Leads to better reviews

To do stacked PRs:

1. Find logical breakpoints in your changes

2. Make new branches for each part

3. Use git cherry-pick to move related commits

4. Open new PRs for each part

5. Close the original PR, linking to the new ones

"Small PRs start long before the work starts. The size of a pull request can be influenced long before the PR is opened." - Artsy Engineering

Tools to Manage PR Size

Want to keep your PRs in check? Here are some handy tools:

Size Checks in Code Review Lists

Add a simple size check to your PR template:

- [ ] PR changes < 200 lines of code
- [ ] If not, split into smaller PRs

Automatic PR Size Checks

Let machines do the heavy lifting:

Bitbucket's team used a bot to flag 400+ line PRs. Result? 32% fewer oversized PRs in just 3 months.

OtterWise

This tool tracks PR size and code quality. One fintech company cut their average PR size from 350 to 180 lines in 6 weeks.

"OtterWise opened our eyes to our PR size problem." - Sarah Chen, Lead Developer at FinTech Co. Inc.

Best Ways to Keep Code Quality High in PRs

Want better code in your pull requests? Here's how:

Write Clear PR Descriptions

Think of your PR description as a roadmap. It should answer:

• What's this PR doing?

• Why do we need it?

• How does it work?

Fun fact: GitHub found PRs with clear descriptions get reviewed 25% faster. That's a big win for your team.

Use Automated Testing

Let machines do the grunt work. Set up CI to test every PR. It catches bugs before humans even look.

Take Airbnb, for example. Their CI setup:

• Runs unit tests

• Checks code style

• Scans for security issues

The result? 30% less manual review time. Not bad, right?

Do Thorough Code Reviews

Good reviews catch problems early. But how do you make them count?

Google's take on code reviews?

"If someone sends you a massive code review, ask them to split it into smaller, buildable chunks."

In other words: Keep it manageable. Your future self will thank you.

Tracking PR Size and Quality

Want to boost your code quality? Keep tabs on your PR size and quality. Here's how:

Key Metrics to Watch

Focus on these numbers:

Google's take? "One business day max for code review responses."

Using Data for Improvement

Got your metrics? Put them to work:

1. Cap PR size

Aim for under 400 lines. Why? Big PRs = tough reviews.

2. Speed up reviews

Slow first reviews? Try:

• Auto-assigning reviewers

• Slack reminders for pending reviews

3. Spot bottlenecks

Too many review cycles? Could mean:

• Oversized PRs

• Need for more review training

OtterWise Reports

OtterWise tracks these metrics for you. It offers:

• Custom PR metric dashboards

• Alerts for large PRs

• Review response time reports

Use tools like this to spot trends and fix issues fast.

Dealing with Size Limit Challenges

Enforcing PR size limits can be tough. Here's how to tackle common issues:

Handling Team Pushback

When teams resist new size rules:

• Share data on how smaller PRs boost review speed and code quality

• Start with gentle guidelines, not strict rules

• Have team leads create smaller PRs to show the benefits

Balancing Size and Complexity

When complex changes clash with size limits:

• Use feature toggles to hide new code until it's ready (Artsy does this)

• Build a "walking skeleton" - a bare-bones implementation connecting all parts

• Separate novel code from routine changes for focused reviews

Keeping Context in Smaller PRs

Don't sacrifice context for size:

• Write clear descriptions explaining the problem and solution

• Open draft PRs early for feedback (like Sepand's TODO lists in PR bodies)

• Link related PRs that are part of a larger change

Real Examples of PR Size Improvement

Success Stories from Big Companies

Tech companies have seen big wins from smaller pull requests (PRs):

1. Artsy

Artsy boosted code quality with feature toggles:

• They hid new code until it was ready

• This let them add code bit by bit

• PRs stayed small and focused

• Reviews got faster

Matt, a dev at Artsy, showed how it works:

• He added a new API field in one PR

• Then, he updated the UI with that field in another PR

Result? Faster reviews, fewer bugs.

2. GitClear

GitClear's "Commit Cruncher" cut review time:

For PR #25610, GitClear took 13.16 minutes to review. GitHub? 22.76 minutes.

PR Metrics: Before and After

A study of 12,638 PRs showed:

What does this mean?

• Small PRs (100-300 lines): 21.86% faster to review

• Big PRs (1,000+ lines): 28.96% faster to review

A team at Swarmia tried smaller PRs:

• They shipped changes in under 200 lines

• Most features took less than two weeks

• Code got better with focused reviews

Wrap-up

PR Size and Code Quality

PR size is a big deal for code quality. Here's why:

• Small PRs get better reviews. Big ones? Engineers put them off.

• Fewer lines, fewer bugs. It's that simple.

• Small changes merge fast. Big ones? Not so much.

• PRs under 400 lines are easier to review. Reviewers catch more issues.

Improving Your PRs

Want better PRs? Try these:

1. Set a limit: Aim for under 200 lines. Over 500? Split it up.

2. Use feature toggles: Hide new code until it's ready.

3. Stack PRs: Break big changes into smaller, linked PRs.

4. Automate size checks: Catch big PRs early.

5. Track your progress: Keep an eye on PR sizes, review times, and bugs.

FAQs

What's a large pull request?

A large PR changes over 400 lines of code. This includes additions, modifications, and deletions across all files. These big PRs are tough to review well.

When is a PR too big?

There's no hard rule, but PRs over 400 lines are usually too big. They cause:

• Slower reviews

• More potential bugs

• Less thorough reviews

What's the best PR size?

Aim for under 200 lines, ideally around 50. Here's why:

• 50-line PRs get merged 40% faster than 250-line ones

• Smaller PRs get 40% more comments per line (better reviews)

• Less code = fewer bugs

Keep your PRs small:

1. Set clear team guidelines

2. Use feature toggles for unfinished work

3. Break big changes into smaller, linked PRs

4. Add automated size checks to your CI/CD pipeline