Software evolves. Eventually some functionality that your program incorporates will be abandoned. This is completely natural. So what do you do with the source code that implements this functionality? Maybe you leave the functions in place but no longer call them. Maybe you comment the code out. Maybe you comment the code out and add a helpful comment above along the lines of, “This is no longer used”. Maybe–but this would be a greenhorn mistake. It’s like the sight gag from the 1995 comedy Kicking and Screaming where a character breaks a glass and then, instead of cleaning it up, puts a note next to it that says, “Broken glass”.
Delete unused code. That’s part of your job. Your fellow developers aren’t psychic, and so have no access to the informal map in your head of which parts of the codebase are up to date. At best someone will waste an afternoon figuring out that your nostalgic curio doesn’t actually do anything. At worst they will not figure this out and extend it. If you think a particular snippet of code should be saved because it may be useful in the future, you may be right, and that’s what version control software is for. It’s not what the head of the main development branch is for. Every line there must always be–to the best of everyone’s ability–perfect, necessary, and complete. Anything else just makes things harder.
The term of art for a non-functioning part of a codebase is “dead code”, but this is the wrong metaphor. Non-functional source isn’t dead code–its necrotic code. To be dead is to be inert, no longer causing trouble. To be necrotic is to be woven in with the healthy tissue around you, infecting it with rot and decay.