Best Practices for Removing Unused Code

Question

I\'d like to know what people\'s best practices are for removing unused code. Personally I\'m a fan of deleting (not just commenting) anything that\'s not currently being used.

Answer 1

A piece of code can have two states.
Either it is active, functioning and tested, in which case it should be in the source control
Or it is obsolete in a way that you can't imagine anyone ever wanting to use it anymore, simply because it is obsolete. In this case it should be deleted.

Not erasing code so that "another developer can find it easily" is a perfectly good reason to keep the code active and compiling. Don't worry about the size of your libraries, the linker removes anything that isn't used.

If you're erasing code and want to warn others of the code that was there and for the reason it was deleted so they won't do the same mistake again, a good comment can be put in place.

Answer 2

I am going to suggest replacing the deleted code with a comment specifying the Work Item against which the code was deleted. My rationale is this provides a "hook" onto which any code review comments can be attached. We're using TFS change sets to do code reviews VS Professional. If the code is 100% deleted there is no hook.

Answer 3

If you are using a source control system, deleting the code is my preferred option.

It won't get in your way when working with the current code, and you'll always have the code in the repository if you ever need it again.

Answer 4

The first thing to remember is all your code should be in source control.

With that in mind, of course you want to delete obsolete code rather than just comment it out. Commented code blocks of any length are dangerous, for at least two reasons:

1. There's a tendency to assume that the comments were maintained with the rest of the code. This isn't true and can lead to problems like bug regressions.
2. It's easy to miss an uncommented closing curly brace (for example) in the middle of a long block.

The deleted code is still available if you really need it, but it's no longer cluttering up your working copies. If you're really concerned about discoverability for the old code you can leave a comment indicating code was removed and the revision number you need to find it. At one line, that's a lot better than what the actual code block was using. It's also much clearer this code has been allowed to lapse, and for exactly how long.

Answer 5

I'm also a fan of deleting unused code.

If I know that the code can be helpful later, I created a branch before deleting the code from the trunk (we're using subversion - so creating branches is very cheap and easy). This allows me to easily get that code back once/if it is needed.

For example, if you have a new feature, which won't be completed for a release, this procedure allows to remove the partial feature from trunk, but you will be able to add it back once you're gonna finish it.

Answer 6

My guess is that even if you comment that it's in the repository, it'll be re-written instead of someone going back and grabbing it.

Not that I've worked in many places with this "no code left behind" policy (just one), but I've NEVER seen someone go back into the repository and get some old code.

However, except for small blocks, I've never seen anyone uncomment someone else's code either!

If you wanted to save it, I'd leave it fully implemented and tested (check in the tests!) but under a condition that will change if the new code is ever needed.

I've had un-needed code just "Turn on" when it was needed, that's a really nice feeling (not that it can always be done).

If you can't be bothered to make it fully functional and tested, then snip it and let the next guy re-write it.