Re:Avoid Else, Return Early (2013)
by zip1234 on Monday March 26, 2018 @09:35AM
(#16678711)
The problem with this is maintaining comments. If you are using a compiled language or even linting, code that is part of the codebased is checked by a machine at least in a cursory way and the code that is there is what runs. The comments are not guaranteed in any way to pertain to the code that is in the repo and there is not a way for a computer to check the meaning of the comment to make sure that it was updated to match the code. Comments can get out of date, which may make them do the opposite of what they are intended for.
[ Parent
| on HN ]
A while back I tried to create a commenting system that explicitly tied comments to blocks of code. The idea was that if you tried to change the code without also changing the comment, or vis versa, a git pre-commit hook would yell at you. Unfortunately it wound up being less tractable than I anticipated, but I think the basic idea has some promise.
Re:Avoid Else, Return Early (2013)
by jasonpeacock on Monday March 26, 2018 @02:56PM
(#16681465)
That's what code reviews are for, to help developers check each other for things that cannot be automatically linted.
> The problem with this is maintaining comments.
That's like saying "the problem with healthcare is that it costs money". Of course comments can get out of date. The solution isn't to throw them out!
"The problem with installing a roof on your house is one day it can be blown off."
There's no alternative for healthcare.
There's alternative to in-code comments answering the question "why" - it's commit messages. They can't be out of date.
But commit messages can easily get plowed under in some annoying "reformatted, I hate tabs/spaces" commit. I do like to see some "why" sprinkled in here and there that will survive those accidents. But I will nonetheless prefer blame output if it is still meaningful. Also, I enjoy a commit that removes redundant comments almost as much as one that removes redundant code.
You can either pass a commit id to git blame to see changes before the reformat happend or you can use git log like this:
git log -L0,10:file.txt