True. But the flip side is that comments can outlive their relevance, accuracy, or purpose.
This is a good reason to reject most comments: they're an additional maintenance cost that can't be automated.
>This is a good reason to reject most comments: they're an additional maintenance cost that can't be automated.
By the same line of reasoning one should reject most code.
A comment that helps the next programmer who's going to look at the code is good. If/when the comment is obsolete, deleting it is easy.
I'm saying this as someone who rarely includes comments in a first commit. Generally I add comments that answer questions that come up in code review, because it's likely that someone else looking at the code will have the same questions my reviewers have.
Yes, you should reject all unnecessary code. If that is "most", then your project might have some problems. ;)
> If/when the comment is obsolete, deleting it is easy.
The hard part is to know if and when the comment is obsolete. It's way too often I stumble upon comments that contradicts the code. Is the code wrong? Is the comment wrong? Often the history reveals that the comment was correct at some earlier time, but the person changing the code didn't think about changing the comment. I think that the mechanism behind this is that after the first read through of the code we tend to stop seeing the comments.
And yet it unfailingly keeps not happening. Not because it's hard to do, but because it's easy to miss.
Implementing every change both in code and comments can maybe be done, but I've neverseen it done, and I don't understand how you'd go about it.
Can't say I've seen a great comment maintenance track record anywhere so far...
I have a really hard time reconciling this with my experiences. Sure, often times comments that explain _what_ is happening can go stale, but I have frequently spent hours debugging, asking in Slack, and picking the collective brains of other developers for a codebase to understand why we do X, or what some test is meant to represent, when a thorough comment ("This tests feature X... for product Y...") could have made it easier to recognize that certain behavior can be removed ("Oh wait that's for this product/workflow which we don't even do anymore -- it's safe to just delete that entire thing"), or understand the nuances of why the Simple Seeming way of doing something is wrong.