4 ms·
I'm lost. Are you talking about meta-level comments, like "here's why this change is being made", that aren't directly tied to any particular line of code? If s
by fenomas 5y ago
I'm lost. Are you talking about meta-level comments, like "here's why this change is being made", that aren't directly tied to any particular line of code? If so, certainly putting that stuff in commits makes sense.
But for regular "explanatory note about this variable/function/etc" comments, how does one work if those things are in commit logs? If you're reading code and something is unclear, do you look back through the commit messages of every commit that's ever touched that line, just in case one of them has something relevant?
- treis 5y agoIDEs can show commit history. But you're right that it can get messy tracing back to the original commit when a file has been changed many times. But for the most part I feel like comments should be automated tests. If a line is there for an edge case it should have a matching test for that edge case. The only exceptions I see are for performance optimizations or some other situation where you can't easily test.
- fenomas 5y ago> IDEs can show commit history. How you check the commit history is beside the point - the question is, do you read the entire commit log history for a chunk of code before editing it? If not, any comments there might as well not exist - functionally speaking you're maintaining an uncommented codebase.
- codedokode 5y agoTests are not a replacement for comments or documentation. Tests check that A() returns x but don't explain what is A, x and why it should return it.
- treis 5y agoThat goes in the test name. You'll have something like Feature A "It should return X in [some edge case]" That's where any link to a use case should be.