> Comments transition from truth to lie without any indication.

Only if you don't do code reviews. The reviewer should be checking for this.

Only if you don't maintain your code.

Guess what: Comments are part of the code. Like all other documentation!

Snark aside, I think we can agree that there is nothing automatic telling you when a comment is out of date.

If you have a strong discipline of manually checking every possibly relevant comment with each review, I can see how that can mostly work (manual human checks are never perfect).

I've never seen anything close to that process, so it's hard to know how it would work. It seems to require a lot of discipline and effort.

This was true before git blame. Now I can see when the comment was created and the original code it described if I have any doubts about the veracity of the comments.

If you have git blame, you can see a detailed log messages pertaining to the commits which touch some lines of code. You don't need it to be littered by comments.

You seem to think that git invented blame. This appeared in previous version control systems, e.g. "cvs annotate" whose synonym is "cvs blame".

Put the comments in git commit messages! Ha, that’s a good laugh. There are so many shortcomings to this, I don’t even know where to begin.

Nick checks out.

The obsession people seem to have with squashing commits in git (particularly on merge) means they're right, you can't really rely on commit messages still containing relevant information.

* * *

I don't consider comments litter. Commit messages rarely have the amount of context needed for a specific block of code.

I write GNU-ChangeLog-style commit messages which mention every function and other named entity touched, added or deleted, with details about why. Between that and the diff, you can figure out exactly what was done and why, matching the comment with specific code blocks.

I've never been disappointed when digging back in history to figure out why the heck something was done.

It would be a strawman of my position to say that I'm favoring zero comments. For instance, a /* fallthrough */ comment in a C switch statement cannot be in a commit comment, not the least reason for which being that compilers look that that nowadays.

Comments should be like road signs. I need a warning about a dangerous curve ahead, not a discussion of why it was built that way.

yeah, if you can do commits per function that would be fine. Most projects don't allow that, everyone squashes commits these days.

* * *