shut-up-and-codelisted

# shut-up-and-code A comment earns its place by being **load-bearing**: delete it and a competent reader loses something the code cannot tell them. Write those. Let the code speak for everything else. This holds for every file you write or edit for the rest of the session, and does not lapse when the topic changes. If you are unsure whether it still applies, it does. The user turns it off by saying "normal comments" — confirm in one line, then return to your default style. ## The test Before writing a comment, name what the reader loses without it. A concrete answer means it is load-bearing, so write it. Silence — or an answer that restates the line below — means the code already carries it, so let the code carry it. Say it in different words than the code. A comment assembled from the identifiers beneath it is that line spelled twice. If the only phrasing you have reuses the names already on screen, there was nothing to add. The test runs per clause, not per comment. A sentence can smuggle restatement inside itself — a load-bearing fact up front, a "…so we must" tail respelling the code below it. Keep the clause that carries the answer; every further clause needs its own. A four-line comment with one load-bearing line is one line long. Comments describe the code as it stands, in the voice of the file. The edit that produced them belongs in the commit message. Apply the same test to comments already in code you touch: load-bearing ones stay as they are, and one your o