3 ms·

> If you change a line of code without doing git-blame on it first you're doing it wrong. Working on a project where this is necessary sounds like a hellish ex

> If you change a line of code without doing git-blame on it first you're doing it wrong. Working on a project where this is necessary sounds like a hellish experience. The place for comments explaining why the code is needed is right next to the code! On an adjacent line!

ajuc 3y ago
> a hellish experience. It's literally 1 click away. Or even just a hover over the margin. > The place for comments explaining why the code is needed is right next to the code! On an adjacent line! And then you refactor the code (from another place) and the function name and parameters change but the comments in adjacent lines remain the same. Ups, the comments lie. After enough time passes it's 50-50 whether a particular comment is still true. The more high-level the comment - the higher likelihood it lies, because high-level comments are by their nature further away from the code they mention (and they always mention code in many places but you won't copy-paste them everywhere relevant, right? DRY and all). So in reality the comments aren't "on the adjacent line" but "on the adjacent line in one of 10 places this code is related to - go look for all of them". On the other hand commit message is always on all lines that changed, if you git blame a line - you see when it was changed last and why, and you can be sure nobody messed with it without changing the commit message.
- kaashif 3y ago
  I'm not saying using git blame is hellish, I'm saying always needing to do it because of all of the things you described sounds hellish. The original comment was that you should always do it, for every line of code.
  - ajuc 3y ago
    Well you should. It costs almost nothing and it can have very high positive impact.
wnoise 3y ago
Why code is needed is different than why change is needed.
wharvle 3y ago
Hard concur. When something might look wrong or misleading to a future reader is exactly the time to comment.

ajuc 3y ago

> a hellish experience. It's literally 1 click away. Or even just a hover over the margin. > The place for comments explaining why the code is needed is right next to the code! On an adjacent line! And then you refactor the code (from another place) and the function name and parameters change but the comments in adjacent lines remain the same. Ups, the comments lie. After enough time passes it's 50-50 whether a particular comment is still true. The more high-level the comment - the higher likelihood it lies, because high-level comments are by their nature further away from the code they mention (and they always mention code in many places but you won't copy-paste them everywhere relevant, right? DRY and all). So in reality the comments aren't "on the adjacent line" but "on the adjacent line in one of 10 places this code is related to - go look for all of them". On the other hand commit message is always on all lines that changed, if you git blame a line - you see when it was changed last and why, and you can be sure nobody messed with it without changing the commit message.

kaashif 3y ago
I'm not saying using git blame is hellish, I'm saying always needing to do it because of all of the things you described sounds hellish. The original comment was that you should always do it, for every line of code.
- ajuc 3y ago
  Well you should. It costs almost nothing and it can have very high positive impact.

wnoise 3y ago

Why code is needed is different than why change is needed.

wharvle 3y ago

Hard concur. When something might look wrong or misleading to a future reader is exactly the time to comment.