Applying the Single Responsibility Principle to Pull Requests
The single-responsibility principle (SRP) usually gets discussed in the context of classes and modules: one thing, one reason to change. That same idea also works well for pull requests.
A good PR should answer one question clearly: what is this change supposed to do?
When a PR mixes a feature, a bug fix, a refactor, and a drive-by cleanup, review gets harder for everyone. The reviewer has to separate the real behavior change from the incidental edits, and that increases the chance that something subtle slips through.
Keep The Intent Narrow
If the ticket is about a feature, keep the PR focused on that feature. If the ticket is about a bug, keep the PR focused on that bug. If you are refactoring, keep the PR focused on the refactor.
That does not mean you should ignore obvious issues forever. It means you should be intentional about scope. A follow-up ticket is often the better place for unrelated cleanup, especially if it touches the same files but not the same behavior.
Why This Matters
Smaller PRs are easier to review because the before-and-after story is simpler. They are also easier to revert when something goes wrong. Just as important, they make the reviewer's job less ambiguous: there is one primary change to validate, not a bundle of unrelated edits competing for attention.
This is especially valuable on a team. You want other engineers to know whether they are looking at new behavior, a mechanical cleanup, or both. That clarity reduces cognitive load and speeds up feedback.
Practical Rules
- Ship the user-facing change first, then do unrelated cleanup in a separate PR.
- If a refactor is required to land the feature safely, keep only the refactor that directly supports the feature.
- If you find another issue while working, open a follow-up ticket unless it is directly blocking the current change.
- If you need a larger cleanup to make the code safe or understandable, call that out explicitly in the PR description.
Be Pragmatic
SRP for PRs is a guideline, not a law. Sometimes you really do need a small amount of incidental cleanup to make the main change work. The point is not to be dogmatic. The point is to make review easier, reduce risk, and keep the purpose of the PR obvious.
If the reviewer can explain the change in one sentence, the PR is probably in good shape.
