[devjab]

I never understood commenting out code when you have version control. I get why people do it, I’ve done it myself and then two days later been confused which of the 3 commented out function was actually the most recent. It’s infinitely more clear from the version control since the history is there for you to zoom through.

[wink]

You would find it if you knew it was there.

I only leave it commented out because it has a reason (they all say that, right?).

I suppose the best way would be to provide a meaningful comment "This is the place where 15 lines of coded finally found their resting place, deleted after the bug they solved was eliminated elsewhere".

But in reality, I've never seen a single of the "we could find it it in git" ever actually find it in git.

[devjab]

Well yes, but you’re not leaving commented out code for anyone other than you. A “sane” git structure will automatically decline your pull request if it contains commented out code.

I say “sane” because I know a lot of places probably allow you to do it. You really don’t want to pollute a code base like that though.

[swiftcoder]

> It’s infinitely more clear from the version control since the history is there for you to zoom through

Only if you already know it is there. There is like... zero history discoverability built in the git. and git's historical search story is pretty bad too.

[devjab]

Well, who other than you would need to know about your commented out code? I’m not suggesting you keep the commented out code as part of your git history, that would never be allowed through a pull request. The changes will be there in the history though, I doubt you’ll need to go back for them, but you could.

[bryanrasmussen]

>I never understood commenting out code when you have version control. I get why people do it,

I'm not suggesting that one should comment out code but I never understood why if they have version control and there is a new bug a significant amount of devs do not actually go through the history to find the working version.

Now - after writing the above and thinking while writing, I am going to suggest scenarios when you want to comment out code.

You write a great bit of code that does not work, you find out it is because API X is not correctly implemented, therefore you have to do a workaround kludge until API X is correctly implemented.

What do you do? I think the optimal solution there would be to comment out the great bit of code above the workaround kludge with a comment - API X has a bug, I have made a bug report out on the API X working group. I suggest checking periodically and then getting rid of the kludge and moving this code in. Dated, so that people can see when they should check.

It's true I have seldom had the pleasure of working with people where this optimal way of doing it would have been at all useful, but it has happened maybe twice over many years. Probably it will only help you out when you see the comment over the coming months, or when you get an email that your bug has been fixed.

I'm sure you can imagine other similar scenarios in which commenting out the code makes more sense than using version control.

[block_dagger]

I think a lot of devs prefer the hover-to-blame feature in their IDE vs searching through history on GitHub.