> But ideally the comments should be executable, as unit tests

For the kinds of comments that answer the "why", if we could do that, we wouldn't need the actual code in the first place.

> making you read them if and only if you break them.

A good "why" comment is supposed to inform you beforehand, so you can make changes effectively and without introducing extra bugs in the process. Unit tests are more of a safety net.

I’m imagining the poster is thinking about things like rust doctests where code in the comments will be executed as tests when you run cargo test on the project. It’s a nice way of being able to ensure that (at least part of) the documentation will correspond to the behavior of the code.

I am thinking of any fast unit test system. Going in seconds from red to green is a thrill.

Unit tests suck at being documentation, and are not a good substitute for the "why" comment. They can catch some mistakes you make with the code under test, but they can't tell you why it is the way it is. At best, they can help you guess, at the cost of having to study the test code itself (which is usually much bigger than the code it tests, and often more complicated). But the thing is, the knowledge of "why" is most valuable to have before you start making changes and break some tests.

This is true, test coverage, especially in code that has to interact with other systems in particular ways will often have ten lines of setup that only matters in the test for every line of actual verification.

On the flip side, I’ve had things like:

    // in case this is malformed, fix formatting so it will still parse
    input = fixInputFormatting(input);

and had a code reviewer ask, “why are you calling fixInputFormatting”?

Nothing to raise the blood pressure like a code review question that is literally answered by a comment on the line immediately preceding where they left the question.

But in this case surely you're better off with

    input = fixInputFormattingIfMalformed(input);

or even

    if (isMalformed(input)) input = fixInputFormatting(input);

I'm with the reviewer on this one. Why is it malformed? Why are you fixing it here and not earlier? Why are you fixing it and not rejecting it? The comment tells me nothing.

I don’t remember the exact comment/cope pair anymore, but it was something that the answer they wanted was exactly what was on the preceding line. Coming up with a simple example to demonstrate that is a surprisingly hard thing to do.