Boy Scout Rule
debt(d9/e3/b5/t5)
Closest to 'silent in production until users hit it' (d9). The detection_hints explicitly state 'automated: no' and the code_pattern is 'technical debt accumulating without any clean-up in PRs' — there is no tool that detects violation of the Boy Scout Rule. Neglect accumulates silently over many commits and is only noticed when the codebase becomes painful to work in.
Closest to 'simple parameterised fix' (e3). The quick_fix describes small, incremental actions (rename a variable, extract a snippet, delete a dead comment). Correcting a pattern of ignoring the rule requires instilling a habit across the team and cleaning up accumulated debt, which is more than a one-liner but still localized — not a cross-cutting architectural refactor.
Closest to 'persistent productivity tax' (b5). The term applies_to all contexts (web, cli, queue-worker), meaning consistent neglect affects every work stream. The common_mistakes show it compounds across every PR and every developer's workflow, but it doesn't define the system's shape on its own — it's a cultural/process debt that slows many work streams without necessarily dictating architecture.
Closest to 'notable trap' (t5). The misconception field explicitly states the canonical wrong belief: developers interpret the rule as licence for large refactors during any ticket, when it means only small, incremental improvements. This is a documented and commonly learned gotcha — notable but not catastrophically counterintuitive compared to analogous concepts.
Also Known As
TL;DR
Explanation
Robert C. Martin's Boy Scout Rule (from Robert Baden-Powell's 'Leave the campsite cleaner than you found it') applied to code: whenever you touch a file, make a small improvement — rename a confusing variable, extract a long method, remove a dead comment. These micro-improvements compound over time, keeping technical debt from accumulating. The rule is pragmatic: improvements should be small and risk-proportionate, not full refactors in the middle of a feature branch.
Common Misconception
Why It Matters
Common Mistakes
- Interpreting the rule as licence to refactor everything you touch — scope improvements to what is directly relevant.
- Making cleanup changes in the same commit as feature changes — separate commits make blame and rollback cleaner.
- Skipping the rule under deadline pressure consistently — this is exactly when debt accumulates fastest.
- Applying it only to formatting and ignoring structural improvements like extracting methods or removing duplication.
Code Examples
// Leaving broken-window code untouched:
function calcTtl($d, $t) { // Cryptic names, never improved
return $d * 86400 + $t; // What does this compute? Magic numbers too
}// Leave the code cleaner than you found it — in the area you're already touching
// Before (you're fixing a bug in this method):
public function calculateTotal($c) { // vague name
$t = 0; // single-letter variable
foreach($c as $i) $t += $i['p']; // magic key 'p'
return $t;
}
// After (bug fixed + scout cleanup — same PR, minimal scope):
public function calculateTotal(array $cartItems): float {
return array_reduce(
$cartItems,
fn(float $total, array $item) => $total + $item['price'],
0.0
);
}