3 ms·
I would prefer to see that rationale in the comments or some implementation doc or something. In the git history it's eventually going to be troublesome to unea
by prodigal_erik 15y ago
I would prefer to see that rationale in the comments or some implementation doc or something. In the git history it's eventually going to be troublesome to unearth, unless the change remains intact enough for "git blame" to give you a pointer to that old commit, or your whole team standardizes keywords for more searchable commit messages. And if your team does have a way to find that explanation, you then need some way for them to discover whether it has become inaccurate over time.
- MostAwesomeDude 15y agoYou are implying that "the team" actually reads that section of the code, and furthermore that they will actually attempt to fix any issues found in that section rather than just go find the original author and ply him with beer to get him to fix it.
- rmccue 15y agoComments about the change itself, and the rationale behind it, should go in commit messages. Comments about the implementation itself should go in the code. Granted, there is some overlap between the two, in which case, go with code only (since it's part of the commit anyway).