Rule 25 of 38 · Chapter IV — Write for the Next Developer
Leave the code better than you found it
Why this rule exists
Codebases decay one rushed change at a time, and they recover the same way. If everyone who touches a file leaves it slightly cleaner — a clearer name, a deleted dead branch, a comment that finally explains the why — quality compounds instead of erodes. The alternative, where everyone steps around the mess because it isn't their job, is how a codebase becomes the thing nobody wants to open.
In practice
When you're already in a file for another reason, fix the small thing you notice: rename the misleading variable, delete the commented-out block, tidy the confusing conditional. Keep these improvements in their own commit so review stays easy. The bar is small and local — leave your campsite cleaner, not rebuild the whole park.
When it doesn't apply
Resist scope creep. If the cleanup is large, risky, or unrelated to your change, note it and file it separately rather than smuggling a refactor into an unrelated diff. And in code with thin test coverage, tread carefully — an "improvement" you can't verify is just a new risk.