I can't even fathom this mindset. Deleting the code and relying on source control removes the issue from top of mind. Also, it will require more work to bring back later. Both of these are very good reasons to temporarily keep commented code around.
> Deleting the code and relying on source control removes the issue from top of mind.
That's the goal. Your top of mind is very limited; use tools like version control to help you conserve it.
> Also, it will require more work to bring back later.
Then you need better version control. You can either grab the reverse diff from the commit removing it and apply that (possibly with conflict resolution against more recent changes), or just grab the original file and copy the block of code out of it.
> Your top of mind is very limited; use tools like version control to help you conserve it.
Seeing a commented block scroll by doesn't waste top of mind. And if you really don't want to see it editors have something called code folding.
> Then you need better version control.
Have you ever tried searching a version history with thousands of commits to find a piece of code that you think you might have written awhile back, but you can't remember enough details about to come up with a good search term? No matter how good your version control is that's going to be a tough proposition.
> Have you ever tried searching a version history with thousands of commits to find a piece of code that you think you might have written awhile back, but you can't remember enough details about to come up with a good search term?
I find that a `author(..) and file(..)` (hg) query gets you at least 90% of the way there if you have things split into a reasonable number of files. From there, running through a few guesses about search terms or even scanning the commit messages is pretty feasible. Date ranging can help, too.
There's so much data in source control - don't navigate by just commit messages.
Tag commits which delete things you suspect you may want to restore later with a descriptive name and message. Occasionally go back and prune those tags when you have nothing better to do.
This assumes that you knew that the code was once there, and where it was. Working on a team with partially implemented features with planned future hooks, it's just easier to keep the intent in the live code (hopefully with some good comments/docs)
Your half-implemented feature will never, ever make it into live code.
Ever.
Just delete it, you commented out code leaving scum. We all hate you. And you smell.
But seriously. Never commit commented out code. It's a cardinal sin and massive code smell. Never leave YAGNI, but maybe one day, hooks in code. Just delete it. It will never make it live and when someone actually comes to do that feature they'll usually half finish the feature before they even find your code, and then won't be 100% sure your code is supposed to do exactly the same feature and so they won't delete your cruft as they don't really know what on earth it's supposed to do.
And on top of that your code won't work because it hasn't been refactored along with all the live code, so all the property names are wrong, it references methods with signatures that have changed and probably even the names of the classes have changed.
Seriously, though, we do it all the time. Successfully. We even write skeleton code, and have other people finish it off, or take the half-baked idea and implement it properly. Sometimes in this sprint, sometimes in the next. We tend not to let these things stagnate though, so if the spec changes, the ideas are usually ripped out along with them. A lot of the cruft eventually comes out during code reviews...
It's definitely an anti-pattern, using one's code base to communicate....but the right team with the right processes, can work for the short-term. (short-term vs long-term is probably the key here)
This wasn't a half-implemented feature. It was a fully implemented and debugged feature. I was experimentally removing it in favor of a different approach and didn't want to have to go dredging through source control or reinvent and debug it later if I decided we needed it.
"dredging"? It sounds like you aren't very familiar with your tools. Commit, delete the code, commit. Now you're a rollback/backout away from getting it back.
