5 ms·

Yep. I make a commit on every little change and every team I've been on makes me squash them on merge. Comments in Git commits are bad. Just comment the code a

Yep. I make a commit on every little change and every team I've been on makes me squash them on merge. Comments in Git commits are bad. Just comment the code and make sure the comments are updated while you're in the code. You can also look at them in a code review. The argument that they get outdated is easily remedied, but people just want to keep claiming they write 'self documented code.'

AlexCoventry 5y ago
Everyone has to be onboard for that to work. Lots of people just never look at comments because they don't trust them.
jt2190 5y ago
I don’t understand. Can you not squash your commits and rewrite the message before you merge? Wouldn’t that preserve the message? (Trying to think of a scenario where it wouldn’t…)
Zitrax 5y ago
Git commit messages and code comments serve very different purposes, I don't see any reason to try to use one for the other or opposite. To me both are important but for different reasons. I don't want to search the blame history of a line of code if a simple comment had been enough, neither would I want to primarily use code comments when bisecting.
johnisgood 5y ago
I dunno if he really meant that, or just said he is explaining the added functionality in detail. I do explain in the commit message the feature I have just added.
u801e 5y ago
> make sure the comments are updated while you're in the code. You can also look at them in a code review. People will invariably forget to update comments and unless the comments show up in context lines of the diff associated with a change, it's likely that reviewers will overlook the need to change them.
- Gibbon1 5y ago
  You comment is a standard explanation for not having comments. Always makes me wonder why stale comments aren't flagged during code review? Seriously failure to update comments should eventually lead to constructive dismissal.
  - sokoloff 5y ago
    I don't think "constructive dismissal" is the phrase is you want there. (That's normally associated with employer wrongdoing or, at a minimum, mischaracterizing the terms of an employee's departure..)

AlexCoventry 5y ago

Everyone has to be onboard for that to work. Lots of people just never look at comments because they don't trust them.

jt2190 5y ago

I don’t understand. Can you not squash your commits and rewrite the message before you merge? Wouldn’t that preserve the message? (Trying to think of a scenario where it wouldn’t…)

Zitrax 5y ago

Git commit messages and code comments serve very different purposes, I don't see any reason to try to use one for the other or opposite. To me both are important but for different reasons. I don't want to search the blame history of a line of code if a simple comment had been enough, neither would I want to primarily use code comments when bisecting.

johnisgood 5y ago

I dunno if he really meant that, or just said he is explaining the added functionality in detail. I do explain in the commit message the feature I have just added.

u801e 5y ago

> make sure the comments are updated while you're in the code. You can also look at them in a code review. People will invariably forget to update comments and unless the comments show up in context lines of the diff associated with a change, it's likely that reviewers will overlook the need to change them.

Gibbon1 5y ago
You comment is a standard explanation for not having comments. Always makes me wonder why stale comments aren't flagged during code review? Seriously failure to update comments should eventually lead to constructive dismissal.
- sokoloff 5y ago
  I don't think "constructive dismissal" is the phrase is you want there. (That's normally associated with employer wrongdoing or, at a minimum, mischaracterizing the terms of an employee's departure..)