5 ms·

You never wonder why particular lines of code happen to do exactly the things they do, in the exact order they do them, when your intuition would tell you that

You never wonder why particular lines of code happen to do exactly the things they do, in the exact order they do them, when your intuition would tell you that it would be a third as many lines if only the code called this or that utility function, or that it obviously doesn't handle the particular corner case of a new bug report? You must work on unusually well commented code bases then; I wouldn't get anything done without git log -p... at a minimum you will quickly find out which generation of maintenance programmer added the odd code in question and what (if any) bug it was intended to fix, so you don't break that use-case. Well, unless you're out of luck and the first generation of them lost the first 5 years of SCM history, that is...

ssmoot 12y ago
No. If the intent behind the source code you're actually looking at is not apparent, then realistically, looking at it's history is probably equally useless. If there aren't tests or specifications to cover the code, I generally assume any bugs are because of a lack of understanding and proceed from there. Scrolling backwards through history and looking at progressively more naive or prototypical implementations isn't going to tell me anything except the code was likely underspecified IME. Comments are infrequent, but when I write them, they're usually to try to clarify particularly complex implementation detail. Not to communicate requirements. Comments aren't the ideal place for that IMO.