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.
In C# you need to say #if false, it doesn't like #if 0. VS colours the inactive code grey to show that it will not be compiled.
ReplyDeleteAre you kidding? Source control systems designed to keep old code accessible! No needs to #if'out it.
ReplyDeleteTAG, I believe I already answered your objection in the original comment. What source control system lets you do a temporal search of the code? Yes, source control keeps the old code so you can access it but you can't ever find it. The only way is if you already know it is there. Perhaps this would work for your own code because you can keep in your head what code you wrote in the past. In a shared code base with people coming and going, it simply doesn't work. Once it is not in the current version of the files, no one will know it was ever there.
ReplyDelete<I>If this code starts causing problems, get rid of it.</I><P>
ReplyDeleteWhy not preface the commented out code with a comment, "This code started causing problems on 04-Nov-2005. It's probably useless, but FWIW, here it is."<P>
<I>If you know it is broken, get rid of it.</I>
Similarly, why not keep it and add a prefacing comment, "This code is broken. I think the problem is xxxxx, but I didn't fix it. FWIW, here it is."
jtl
PingBack from http://copyrightrenewalsblog.info/steve-rowes-blog-you-arent-gonna-need-it-or-are-you/
ReplyDelete