4 ms·
When tests go stale the build goes red, and you know to fix things. Comments transition from truth to lie without any indication.
by BurningFrog 4y ago
When tests go stale the build goes red, and you know to fix things.
Comments transition from truth to lie without any indication.
- vkou 4y ago> Comments transition from truth to lie without any indication. Only if you don't do code reviews. The reviewer should be checking for this.
- still_grokking 4y agoOnly if you don't maintain your code. Guess what: Comments are part of the code. Like all other documentation!
- BurningFrog 4y agoSnark 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.
- deleted 4y ago[deleted]
- linuxftw 4y agoThis 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.
- kazinator 4y agoIf 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".
- TedDoesntTalk 4y agoPut 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.
- kazinator 4y agoNick checks out?
- Izkata 4y agoThe 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.
- kazinator 4y agoSquashing commits in this way would not have been allowed anywhere I've worked in at least 20 years. This is a strawman argument. Let's assume best CM practices (no vandalism of change sets when moving changes among branches), best practices for commit messages and best practices for commenting. Commit messages win. Code comments should be like road signs. E.g. how high can your truck be to pass under the upcoming bridge. Not blueprints for the bridge, or paragraphs about why it was built there, what communities it serves. (That information must exist and be available, just not on the bridge.)
- linuxftw 4y agoI don't consider comments litter. Commit messages rarely have the amount of context needed for a specific block of code.
- kazinator 4y agoI 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.