What do you do with unused code in your legacy applications? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 4 years ago.

Improve this question 开发者_如何学Python

On huge legacy applications it is fairly common to see change in business rules leading to unused code. Is the deleting the best way? or Are there any standards of marking the unused code? SCM does help to get the old code back if needed. Also this is specific to .NET code bases.

---

1. Check old project into Source Control.
2. Delete unused code.
3. Profit!!

---

1. Mark it obsolete. http://msdn.microsoft.com/en-us/library/aa664623%28VS.71%29.aspx
2. Next cycle, comment the code out & make appropriate remarks. Set a region around the code block so that it collapses nicely & doesn't eat up a lot of visual space.
3. Next cycle, delete the code.

This way you don't surprise your teammates too badly if you need to deprecate some code that you're assigned to but which they need to make calls to. But allows you to make those needed changes!

---

I always delete unused code. This is one of the benefits of source control.

---

Take some advice from Michael Jackson:

Just delete it... delete it... delete it... delete it...

No one wants to be defeated

Showin' how funky and strong is your fight

It doesn't matter who's wrong or right

Just delete it... delete it... just delete it... delete it...

---

I believe deleting is a good way to keep the code cleaner.

If you dont delete, eg: comment out, or create obselete entities to store them, i have seen some mess like this.

and this is why you have repositories, branches, tags, etc..

I find it better to delete it. if the code is already in repository.

---

I usually mark that obsolete:

    /// <summary>
    /// Purpose of this method
    /// </summary>
    /// <param name="args">Argument 1</param>
    [Obsolete("This method is obsolete, use NewMethod instead")]
    public void SampleMethod(string args)
    {
        //code
    }

    /// <summary>
    /// Purpose of this method
    /// </summary>
    /// <param name="args">Argument 1</param>
    public void NewMethod(string args)
    {
        //code
    }

Now the compiler will provide a warning whenever the method marked as Obsolete is used.

---

The best way to mark unused legacy code is to delete it. It serves no purpose other than to confuse new developers to the team.

In my old team we actually turned this into a competition we named the Grim Repear competition. Who could find and delete the largest amount of unused / dead code in the code base. Negative points were awarded for deleting dead code and positive points for adding dead code. Lowest score wins.

---

If I have code I no longer use, I sell it on Craigslist.

---

A good place to apply a lesson from the book Pragmatic Programmer.

Backup and then delete all unused code. Trust me it will save developers from future headache. If you hesitate thinking you might need some future functionality based on commented out code, it's not even worth the pain of trying to understand unused code or logic. Better start with clean state of mind without the need to decipher obviously half-baked, untested code anyway.

---

I prefer to delete it. Source control will keep the history of what was there (and who removed it). I hate searching code and seeing results in commented out code - especially when code is commented using /*...*/ which you can't see on in the find files result instead of \\ which at least gives me a chance of seeing that the result is commented out.

---

Definitely delete unused code. In my experience the biggest problems with legacy codebases is understanding whats going on code - less code means less to understand, making your job easier.

Like you say you can always get it back if you are using source control (you are using source control, right?) and unless you are doing anything a little odd (like dynamically compiling code or loading code through reflection), you are probably going to find out pretty quickly if you deleted the wrong code as your build will fail.

---

What if the code for some functionality which is not needed, but might be needed in future, is scattered throughout a program? Using #ifdef to control such code (keeping in one file a master list of all #define labels used for that purpose) may allow the feature to be enabled or disabled at will; trying to reincorporate all the little bits of code from a version-control system would seem more difficult.

---

I think the best way is doing the version control of your project for example SVN, CVS. And then delete the unused code . To reduce the source file size being compile and avoid to get messy with unused code.

---

Personally, I delete the code I don't use and rely on source control to keep track of it. I don't use VSS though and wouldn't.

There is one exception to this rule though ... Sometimes, if I deleted code in a spot where it's too tempting for somebody else to think it needs to be there, I leave it commented with a quick note so they don't redo my undone work.

---

Delete unused code in your legacy application.

If you have source control deleting the unused code will not hurt anything because its history is keep in whatever version control software you are using. Clean code helps the next developer when he or she has to go in and make changes. Old code only confuses the issue when changes have to be made.

---

I delete the code, but first I make sure that it won't cause any troubles later. If I need it later I get it from the source control and I use one nice feature - code compare and I can see what is what is changed. I don't comment it the unused code, because if other developer is looking at the code it is hard to understand why it is not used (especially if the developer doesn't put comment for the reason). So deleting the code will keep it simple and clear.

---

I believe this was answered at the Refuctoring conference - http://www.waterfall2006.com when discussing the "Rainy Day Module" --you should write spare code just in case somebody needs it later...

class SpareCode {
  private int spareInteger;
  private String luckyString;
  private bool youNeverKnow ;
public void spareLogic() {
  spareInteger = 1;
  if ( youNeverKnow ) {
    spareInteger++;
  }
  System.out.println( luckyString);
}

---

I comment it out the same way I comment out my System.out.println's before going live.