Guidelines for Keeping Change Lists Small and Effective in Code Review

Why a CL Must Be Small

Faster code review . Reviewers can more easily find a 5‑minute slot for a small CL than allocate 30 minutes for a large one.

More thorough review . Large CLs overwhelm reviewers, causing important comments to be missed.

Lower risk of introducing bugs . Small CLs contain fewer changes, making impact analysis easier.

Less wasted work if rejected . A huge CL that is rejected discards a lot of effort.

Easier to merge . Large CLs often conflict with other concurrent changes, requiring frequent merges.

Better code design . Improving a small CL’s design is simpler than tackling a massive change set.

Reduces blocking and keeps work continuous . An atomic CL lets you continue other tasks while waiting for review.

Simpler rollbacks . Small CLs affect fewer files, making rollback operations less complex.

Reviewers may outright reject an overly large CL, asking the author to split it into smaller, manageable pieces.

How Small Should a CL Be

Ideally a CL should contain fewer than 800 lines, most should stay under 400 lines, and the best practice is to keep it under 100 lines.

Studies show a reviewer can comfortably review up to 500 lines per hour, and a CL under 400 lines maximizes efficiency.

How to Properly Reduce the Size of a CL

Each CL should address a single, tiny change that solves one problem.

A CL is usually a part of a larger feature, not the whole feature; teams should agree on an acceptable size.

Include related test code; if automated tests cannot be added, describe a TestPlan in the commit message.

Provide all necessary context—description, existing code, and any prior related CLs—to the reviewer.

After merging, the CL must not break the build or production deployment.

Avoid making the CL so small that it becomes hard to understand; if a new API is added, its usage should be in the same CL.

When Are Large CLs Acceptable?

If an entire file is deleted, the CL can be treated as a single line change regardless of the file size.

When a trusted automated refactoring tool generates a large CL, reviewers may accept a bigger change as long as merge and testing requirements are still met.

How to Make CLs Smaller in the Right Way

Split Files

Group files that need different reviewers but are otherwise independent, and submit them as separate CLs while maintaining the correct order.

Separate Refactoring from New Features or Fixes

Keep refactoring work in its own CL separate from feature additions or bug fixes; small clean‑up changes can stay with the functional CL, but large refactors should be isolated.

What If a CL Cannot Be Made Smaller?

If a CL appears inevitably large, first consider adding a preceding refactoring‑only CL to pave the way for cleaner changes, and discuss possible splits with the team.

If no split is feasible, obtain explicit reviewer consent, proceed with heightened caution, ensure extensive testing, and monitor the change closely to avoid bugs.

Other Considerations

Don’t Let the Build Fail

When multiple dependent CLs exist, ensure each CL leaves the system in a build‑able state to avoid blocking other developers.

A CL that introduces a failing test is not a complete work unit.

CLs Should Include Corresponding Test Code

Every CL that adds or modifies logic must be accompanied by new or updated tests; pure refactoring CLs should also include tests when possible.

Independent test changes can be placed in a separate CL before the functional CL, following the same principles of isolation and verification.