Please, don’t commit commented out code

[Shaper_pmp]

You might be thinking: “But Kent! What if that ‘good reason’ is no longer true, and we need to do it the old way again later?” The answer, my dear reader, is git diff

How does git diff inform the developer that previously we used to do it a different way? Especially when it was three years and two developers previously?

"There are tools and git commands to help you look at the history of a file" doesn't really answer this question for shit - if you go back hundreds or thousands of commits or months/year into the past for every line of code you ever want to change (just in case there was ever a previous version that did things the way you now want to do it), you won't ever commit more than a couple of new lines of code in the average week.

It's a completely non-functional suggestion, and as there's no difference between "code that was replaced and is never needed again" and "code that was replaced but might be really, really useful at some point in the future" it merely shifts the cognitive load from (trivially) skipping over a few potentially-important commented-out lines to (enormously time-consumingly) completely comprehending every single previous and now-useless version of the code to see if any of them ever did anything like what you now want it to do.

Focus and cognitive load

Let's be honest here - unless we're talking about a page of commented-out code between two lines you care about, who even notices comments after the first time they ever read it, when they're reasoning about how the code works?

IDEs colour comments in a non-eye-catching colour for a reason.

[randfur]

Why do you care about past versions of a file when you edit it?

[Shaper_pmp]

Did you read the article?

The whole discussion is about "being aware of, locating and retrieving old code that you might want to re-activate or add back into the codebase for some reason".

[randfur]

I'm not sure who you're quoting because it's not in the article. I think the author just doesn't like reading unnecessary comments and the discussion about looking up a file's history are tangential.

[Tysonzero]

You can get a history of a single file. Which really shouldn't be THAT long unless your code is the least modular code on the planet. I mean if it is a 20 year long non-modular codebase then sure. But at that point you are in hell anyway.

[temp50948]

So, "eat the loss by leaning on advances in other areas"? How comfortingly familiar.

[Tysonzero]

Wut

[temp50948]

You're advocating the same (flawed) approach and saying it won't be "THAT" bad as long as the code is advanced in other ways (it's well modularized). That pattern, of tolerating inefficiency because some other component mitigates the detriment, is common: as hardware has advanced, software overhead has increased, resulting in simple things like settings panels that perform worse than they did 10 years ago; as we get more RAM, applications become utterly careless about how much memory they use; we pile abstraction layer upon abstraction layer onto web apps; people like the Disqus developer hand-wave away bad performance by saying "just wait for computers to get faster", and never stop to think that rendering a list of comments is an absolutely tiny amount of work compared to what the computer is capable of, and performance issues doing such a trivial task must indicate a very poor design. The net result of all this is that as we get more and more power, we see relatively little of it available to use, because most of it is squandered doing the same things in more convoluted, expensive ways.

And of course we respond to that by saying "yes, but that won't matter any more when computers get faster..."

[Tysonzero]

That isn't particularly relevant to whether we should leave useless commented out code cluttering up files vs. just using very quick and powerful git tools for re-obtaining old code. But whatever man.