Boy Scout Rule

Boy Scout rule

The rule borrows a camping maxim: leave the campground cleaner than you found it. Applied to code, each commit improves the lines it already touches. The failure mode is not neglect but its mirror: a one-line fix swells into a refactor no reviewer signed up for, and the original change drowns.

Method

1. Scope cleanup to the diff you already own. Improve only lines the primary change forces you to read or edit. A function three screens away may be ugly, but if you did not touch it, leave it and note it elsewhere.
2. Cap the tax at a few minutes. Rename one unclear variable, extract one magic number to a named constant, delete one dead branch. The moment the cleanup wants its own tests, stop and split it into a separate change.
3. Separate cleanup commits from behavior commits. Commit the rename or the reflow on its own, then the bug fix on top. A reviewer skims the mechanical diff and reads the real one closely, instead of untangling both.
4. Prefer reversible, low-risk edits. Formatting, naming, extracting a constant, tightening a type: yes. Reordering call sequences, changing error handling, swapping a data structure: no, those are changes in their own right.
5. Format the touched file, not the repo. Run prettier --write path/to/file or ruff check --fix path/to/file. A repo-wide reformat buries your real change under thousands of unrelated lines and poisons the blame history.
6. File larger rot, do not chase it. Open a tracking issue naming the file and line, or add a comment linking that issue number. The rule improves what you pass through; it does not license a detour into a rewrite.

Litmus tests

• Can a reviewer state the commit's single purpose after reading the diff?
• Would reverting the cleanup while keeping the fix leave both still working?
• Did the touched-file count grow only because the real change reached there?
• Could you drop the cleanup entirely and still ship the fix on its own?

Boundaries

On code you had no other reason to open, the rule does not apply: a dedicated refactoring pass is a planned task with its own review, not an opportunistic edit. Defer to team convention when a file is mid-migration or under a freeze.