4 ms·
> Why (comments) That's what we do in my current company, but I vastly preferred what we used to do in my previous company, which was: > Why (commit descripti
by izietto 4y ago
> Why (comments)
That's what we do in my current company, but I vastly preferred what we used to do in my previous company, which was:
> Why (commit description)
which prevents comments obsolescence and code dirt
- pydry 4y agoIME commit descriptions almost never get read by anyone.
- izietto 4y agoIm my previous company we used to write them and used to read them, and used to get frustrated when some old commit didn't have enough description. In this company noone cares and we even have squash & merge mode with description truncation, but methods comments can be longer than methods themselves. It's a question of team mindset I guess
- sethammons 4y agoAnd the latest commit is "shifted all indentation per linter" by someone who didn't write the code. Viewing the history of a file is vastly more a pain in the ass to a useful "why" comment.
- izietto 4y ago> And the latest commit is "shifted all indentation per linter" by someone who didn't write the code IME it's not like that at all, commits like "shifted all indentation per linter" are not so common. It's also easy to skip them. > Useful "Why" comments "Why" comments are not so useful to me, I guess that is the point. The add noise in the code that can be moved elsewhere. Consider that I'm not talking about specific implementation choices comments, like # using heapsort instead of quicksort # because we care about the worst case heapsort(data) which is perfectly fine to be in the code, I'm talking about "why" details that may be not present in the Jira/Whatever issue because they are related to e.g. why a bug raised up from a technical point of view.