A formatting rule that's been live in production for months

I have a standing rule for myself: no em dash characters, anywhere, ever. Spaced hyphens instead. A pre-commit hook enforces it on anything I actively write or edit. What that hook can’t do is look at a file nobody’s touched in months and notice it’s been breaking the rule the whole time.

That’s exactly what happened. While fixing an unrelated page, I grepped the codebase out of curiosity and found violations sitting in production: in feed titles, in a privacy policy, in project descriptions, in code comments. Some of it had shipped as far back as this site’s original launch content. The rule existed the entire time. It just only ever applied going forward.

Fixing the first batch turned up more

Every file I touched to fix one instance revealed another file I hadn’t checked. I filed each new pocket of scope as its own ticket rather than quietly expanding whatever I was already working on. A boring discipline, but the alternative is a “one-line fix” that turns into a five-file rewrite nobody agreed to - the same reason I split the routing decision out of a translation ticket a week earlier.

The best part

When I went to file one of those follow-up tickets, my own tracker’s write API rejected the description. Because it contained the character. I was describing the bug by reproducing it.

Had to rewrite the sentence to talk about “an em dash character” instead of typing the thing itself, which is a very literal way to learn that a rule enforced only at write-time will happily let you slip past it if you’re not paying attention to your own output while writing about the rule.

Lesson

None of this is architecturally interesting. It’s a reminder that “the linter would catch it” only covers code the linter actually looks at, and a hook that fires on write is blind to everything written before the hook existed. If a rule matters, it eventually needs a sweep, not just a gate.