Comment the why, not the what

Why this rule exists

The code already says what it does; the reader can see that. What the code cannot say is why it does it — the constraint, the trade-off, the bug that this odd-looking line prevents. Comments that restate the mechanics go stale and add noise, while comments that capture intent survive refactors and answer the question that actually stops a future reader cold.

In practice

Comment the reasons: why this order matters, why this value and not the obvious one, what breaks if you "simplify" it. Delete comments that merely narrate the next line. When you feel the urge to explain what the code does, first try to make the code itself say it through better names; save the comment for the why that names alone can't carry.

Example

// increment retry count
retries++;

// Gateway dedupes within 2s, so a fast
// retry is silently dropped; back off first.
retries++;

When it doesn't apply

Public APIs, published interfaces, and dense algorithms benefit from descriptive documentation of what and how, since readers there may never see the implementation. Regulatory or safety-critical code sometimes documents the obvious on purpose.