I like leaving old code littered around, either commented out or disabled by feature flags. Then, when my energy/concentration levels are too low for real work, it's a strangely satisfying task going back and cleaning up and finally deleting that stuff.

While this may be fine for you, it sucks for people reading the coding and searching it. Reading code is already a high concentration task, having to purposely ignore blocks of non-functional code makes it harder than it has to be. Also, now I can't just grep the codebase, I need to see the surrounding code as well to see if the search results are valid.

That is totally true when the code is behind a feature flag, rather than commented out. Most people can skip commented code just fine, since it looks like... commented out code, rather than comments intended to be read.

But even in the feature flag case, it serves a purpose by allowing old code to be removed in 2 stages rather than 1 (divide and conquer).

It means the old code still compiles, just in case it needs to be reinstated in a hurry.

Like others have said, you may be surprised! Normally commented out code is at least highlighted differently in more editors. However, it is not unusual for people to complain to me that "if (blah)" is unreadable and must be formatted "if(blah)" (which honestly blows my mind -- you'd think it would be the other way around, if anything!)

One of the biggest thing that catches me out with commented out code is wondering why it is commented out. Is it desirable, but not working for some reason? Is it undesirable, but not deleted for some reason? Is the new code an experiment? Is the old code an experiment? If it's an experiment, am I sure the previous person reinstated the correct code?

Even if you say it can be reinstated in a hurry, why would it need to be? When I'm reading the code, that's one of the questions I'll be thinking about. If I see commented out code, I'll start walking back in history and seeing why the code was replaced. Then I'll be wondering if there is some work flow that perhaps we need to retain for some reason.

All of this takes time. If you really want the code to be gone, it's better for me if you remove it. Then I don't have to wonder why it is there.

I lead a crusade against commented out code and refuse to accept any PRs at work with commented out code. It makes most code search tools useless and adds tons of visual clutter (especially for our colleagues with ADD/ADHD)

Leaving commenter it code is like leaving full trash bags on your kitchen floor. Why are they there? Could the be necessary at some point? Is there a specific time we need to get rid of them?

I agree with you, commented out code is not ok, unless it is an example or pseudo code. The rest is trash and has no place in any reasonable codebase. If you want to see what the code was like six months ago, use git.

> Most people can skip commented code just fine, since it looks like... commented out code

Line comments, yes, but not for block comments or #if 0 disabled sections -- if your search result comes from the middle of one of those, it does not look like a comment without the context, and can mislead you.

Reading this makes me realize programming editors should have an optional search flag to skip comments. It shouldn’t be that difficult.

I am going to give this a shot.

Thank you!

> "don't touch it except to add things, you have no idea what depends on that chunk of code"

To me that's just a symptom of a system that lacks good test coverage. Being able to remove things that you believe to be unused and seeing if it's safe or not is one of the biggest benefits of test coverage. That and, of course, knowing if your "fix" doesn't break things far away that depend on it.