5 ms·

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

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.

IshKebab 9y ago
> 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!
- ajuc 9y ago
  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.
  - usrusr 9y ago
    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.
    - vk23 9y ago
      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
  - TomMarius 9y ago
    What? So in my case I'm supposed to browse literally millions of commit messages in order to understand the code?
- YCode 9y ago
  "The problem with installing a roof on your house is one day it can be blown off."
nemo1618 9y ago
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.
jasonpeacock 9y ago
That's what code reviews are for, to help developers check each other for things that cannot be automatically linted.

IshKebab 9y ago

> 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!

ajuc 9y ago
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.
- usrusr 9y ago
  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.
  - vk23 9y ago
    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
- TomMarius 9y ago
  What? So in my case I'm supposed to browse literally millions of commit messages in order to understand the code?
YCode 9y ago
"The problem with installing a roof on your house is one day it can be blown off."

nemo1618 9y ago

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.

jasonpeacock 9y ago

That's what code reviews are for, to help developers check each other for things that cannot be automatically linted.