The Formatter Tidied a Corpse

A file had been sitting on our main branch for thirteen months, and it had never once been valid code.

I found it while chasing something unrelated. The name was the giveaway: a dotted prefix with a process number in it, the pattern an editor uses when it saves a file atomically. Write the new contents to a scratch name, then rename over the target. The rename is what makes the save atomic. If the process dies in between, the scratch file is simply left behind.

That is what happened, and then somebody committed it.

What was in it: the first thirty-odd lines of a real page component. The directive at the top, then the import block, and then it stopped. No component. No export. The last line was a comment cut off in the middle of a character — not mid-word, mid-byte-sequence, which is what a truncated write looks like from the inside.

So: eight hundred-odd bytes of nothing, committed by accident, carried on the default branch for more than a year.

The part that made me stop

About a month after it landed, a second commit touched the file.

A formatter had run over it and added semicolons.

That is the whole detail, and I have been thinking about it since. Punctuation was normalised in a file that had nothing to punctuate. The file got slightly larger. By the only standard the tool had, it was improved.

I had assumed junk survives in a repository by being invisible. Nobody opens it, nobody greps it, it sits below the waterline. But this one was not invisible. It had been handled. Its history showed two commits, and the second was maintenance — the kind of commit that signals somebody is keeping a file in order.

It survived because it looked tended.

What tooling can and cannot ask

Every automated check we run is a function of what is present. The formatter asks whether this file is formatted. The linter asks whether this file follows the rules. The type checker asks whether these types line up. The dependency audit asks whether these versions are current.

Every one of them takes the file as given and asks whether it is in good order. Not one of them can ask whether it belongs there at all.

So a tool will happily make a wrong file tidier, and tidiness is the exact property that stops a person asking the only question that would have deleted it. Grooming reads as ownership. A file that tools touch looks maintained, and maintained looks like a decision somebody made on purpose.

That asymmetry is structural rather than a gap in our setup. A tool can only improve what it is pointed at, and pointing it at a file already assumes the file belongs. Every pass it makes afterwards quietly adds to the evidence that someone decided so.

What I would do differently

Nothing clever, which is becoming a theme with me. Two things.

First, a filename matching an editor's temp-file pattern should never have been committable. That is one ignore rule, and we had thirteen months to write it.

Second, and the part I will actually carry: I now read a tidy maintenance history as much weaker evidence than I used to. "This file has been updated recently" tells me a tool ran. It does not tell me a person read it. Those two facts look identical in a log, and they are not remotely the same thing.

The general form, as far as I can tell, is that automated upkeep confers the appearance of care without any of the substance, and the appearance is enough to stop anyone looking harder. Our tools are all built to reward what is present and in order. Not one of them has any reason to tell us that something should not have been there.