Comment by slaymaker1907
5 years ago
Version control is not immediately visible to future developers. You need to know that there is something to look for, particularly if it is a frequently changed file.
5 years ago
Version control is not immediately visible to future developers. You need to know that there is something to look for, particularly if it is a frequently changed file.
Really the only time a future developer will care about the old code is when there's a bug in the current code. (Or maybe an edge case like a request to "make it work like it used to in v1.0").
Looking at history via "blame" is useful to see why a bug was introduced (was it fixing another bug, and if so, is your fix going to break that bug again?), and how long it's existed for.
Leaving old code commented out doesn't help either with of those things. Unless maybe it's accompanied by lots of comments and date stamps, in which case you've not only re-invented a very crappy, half-baked version control system, but also made the code hard to read and work with.
git blame only tells you information about the last time a line was changed. If the code is commented out, I can quickly find the version said code was commented out.
Git blame also doesn't help when the history gets truncated for performance reasons.
I kind of agree; I've never looked in a file's history to see if something had been solved previously. I don't recall looking in history more than a week back to restore some deleted code either. In practice, I just rewrite code instead, also with the mindset that I'm a better programmer today than I was yesterday, and that in my head at least, writing that bit of code is trivial.
But overall, if commented code ends up in version control, it probably could have been removed.