4 ms·
> In the case it is or it really needs an explanation it stays in the codebase, otherwise you take it, e.g. to GitHub issues or PR comments. Another thing that
by chriswarbo 3y ago
> In the case it is or it really needs an explanation it stays in the codebase, otherwise you take it, e.g. to GitHub issues or PR comments.
Another thing that's easy, but often overlooked: putting relevant URLs in comments. The best comments explain why some approach was taken; linking to a discussion on JIRA, or the Stack Overflow answer we c̶o̶p̶y̶-̶p̶a̶s̶t̶e̶d̶ ̶f̶r̶o̶m̶ used as inspiration, is (a) quicker than writing a whole explanation, and (b) gives better evidence of what's going on (e.g. that the CTO explicitly asked for this-or-that; or that the SO question now has a better answer; etc.)
- cdogl 3y agoI prefer clean code that doesn’t have comments except as doc strings for various parsers on declarations and in areas that are particularly surprising. If I want to know why something was done, I expect to be able to use git log or git blame on the file or line and get find a commit message, issue tracker link or pull request reference that I can pursue.
- thfuran 3y agoBut then a single minor refactor means you have to dig through history after puzzling over something for long enough to decide that it's definitely no obvious instead of just seeing an inline explanation (or at least a link to one).
- indymike 3y agoIssue trackers, vcs and employees change. A meaningful comment stay as long as it is meaningful.
- avgcorrection 3y agoA lot of commits in Linux contain links to where they were discussed (Kernel Lore archive or something).