The Boy Scout Rule
Always leave the code cleaner than you found it.
The Boy Scout Rule was articulated by Robert C. Martin ('Uncle Bob') in his contribution to 97 Things Every Programmer Should Know (Henney, ed., 2010), adapting the Boy Scouts of America's outdoor ethic ('always leave the campground cleaner than you found it') to software development. The principle prescribes that programmers should make small improvements to the code they touch in the course of normal work — fix a misnamed variable, simplify an awkward conditional, extract a poorly-named method — even when the immediate task doesn't require those changes. The rationale is that codebases erode over time when each contributor leaves problems for the next, and that small continuous improvements compound to maintain quality where one-shot cleanup projects fail to. The rule complements Refactoring (Fowler) by lowering the threshold for making improvements: rather than waiting for explicit refactoring time, take the small win when you see it. Critics have noted that boy-scout improvements can produce thrashing in collaborative codebases (constant style and naming changes that produce merge conflicts and diff noise without proportionate benefit), and that the practice works best when bounded by team conventions about what counts as 'cleaner.'
Core components
- Continuous small improvements while in the codebase
- Lower threshold than dedicated refactoring time
- Compounding effect of small wins over time
- Connection to Clean Code values
- Adaptation of Boy Scouts of America outdoor ethic
- Bounded by team conventions about 'cleaner'
- Distinction from major refactoring efforts
Primary use case
Cultural practice in software craftsmanship communities; complement to refactoring discipline; teaching tool for sustainable codebase maintenance; reference in code review conversations; framework for thinking about how codebases evolve.
Common criticisms
- Can produce thrashing in collaborative codebases — constant style and naming changes that produce merge conflicts, diff noise, and code-review burden disproportionate to benefit
- 'cleaner' is subjective and a small improvement to one person can be a regression to another
- works best when bounded by explicit team conventions, otherwise becomes individual style preferences masquerading as improvement
- tension with separate-changes-from-features discipline that some teams maintain (refactoring should be its own commit, not bundled with feature work)
- can become procrastination disguised as productive work
- the rule's apparent simplicity masks judgment about which improvements are worth the change cost.
Lineage
- Child of
- Refactoring
- Siblings
- Refactoring
- Derived from
- Refactoring