A coworker recently pointed me at this page from the C2 Extreme Programming Wiki.  The basic theory is that, if you find code that isn't being used, delete it.  That is fair enough.  The controversy comes when the code in question is potentially useful in the future.  What then do you do?  The XP advocates on C2 say you should delete that as well.  I don't agree.  If the code in question is potentially useful in the future, I suggest commenting it out (most likely using #if 0).  The arguments against leaving the code in generally revolve around confusing someone.  They might run into the code and try to understand it only to figure out later that it isn't called.  They might be searching the code and  run across it.  There is also an argument that the code will affect compilation times.  If you comment out the code, none of these apply.  The response is often why not just delete the code and if someone really needs it, they can go back in the source control system and retrieve it.  In theory, they can.  In practice, they can't.  I haven't run across a source control system that allows for efficient temporal searching.  Without that, the only way to know that the code exists is to remember that it does.  Not only that, but you also have to remember when it existed.  Somehow, I think that is unlikely to happen very often.  This leads us then to Steve's rules for retaining dead code.  Retain dead code iff:

1)  It does something that will potentially be useful in this area of the code later.  An example might be a slow c-based algorithm for something that is now optimized in assembly.  Someday you may have to port to a new system and you'll want that reference code.

2)  It is not causing you problems.  If this code starts causing problems, get rid of it.

3)  The code works.  If you know it is broken, get rid of it.

This also leads to a feature request for authors of code editors:  Please color code the code between #if 0 and #endif blocks as a comment.