> He repeats the typical line of “Delete code that’s not used instead of commenting it out, because you can always recover it from VCS.” (That’s a view that I’ve [controversially] started to turn against, for the same reason that “you can recover it from backups” is not a compelling reason to delete files currently not in use.)
That's an interesting take. I've usually encouraged removing commented code because every line of code is a liability, even if commented out.
I agree that recovering from VCS is something that never actually happens. Mostly because the code is forgotten.
Still, commented-out code is generally worthless and should be deleted. Unless it is actively being worked on and only commented out to achieve some short-term goal. In which case it should also not be commented out but instead live on a branch.
Occasionally you might have two flows and you're not sure which is best. But in that case keep them in separate functions and one of those will not be used but can still be covered with tests. And all static analysis tools will work on it. Just needs a comment about why this unused code is there.
Commented out code in downstream forks is particularly bad as it either generates spurious merge problems ( // style commenting means you’ll have to do manual resolution for every line in the commented out sections) or hides real changes altogether (/* */ comments allow whole new functions to be added inside the commented region and go unnoticed - which might cause a compilation failure, but might also just result in different method resolution).
Maybe put a comment about the removal if you want something that can easily lead back to the commit which did it.
That's an interesting take. I've usually encouraged removing commented code because every line of code is a liability, even if commented out.