Could someone explain the pros of deleting (or keeping) unused code?

Question

I have heard many times that unused code must be deleted from the project. However it is not clear for me \"why?\".

My points for not deleting that are:

Answer 1

First of all you should always use a source control tool to manage your projects and hence removing unused code is a good practice as you can always go back using source control to get the removed code. For me the reason to remove unused code is that only the person who know the code is unused knows about it, someone else in the team will come across that code and try to figure out what it does and how it fits in the whole application and will feel disappointed after so much effort that the code is not used at all :)

Answer 2

@suspectus has done an excellent job of presenting the reasons for deleting code; I would like to address your individual bullets for keeping code.

• Code is already written, and efforts are spent

But if the already-written code is not in use, this is cost only without (future) value. It is effort invested in vain, and preserving the unused product of those efforts does not validate those efforts. We keep code because it is useful, now, not as some kind of memorial to the efforts of the authors.

• Code may be tested on syntetical and real environment

I'm sorry, I don't know what you mean by this.

• If organized well (grouped, separate package, loosely coupled etc) it doesn't disturbs you on overall code analysis or refactoring

If it exists in the code base, no matter how well organized, it contributes to the maintenance and comprehension burden. True, it can be organized so as to be less of a burden, but if it's gone, it's no burden at all.

• Code may be used in future

In the Agile school, we say YAGNI: You Ain't Gonna Need It. Yes, you might possibly have a use for it in the future, but we can't know enough today about tomorrow's needs to be able to predict that with any kind of reliability. To think otherwise is arrogance tending toward hubris. What we can know about tomorrow is: we want our code base to be easy to modify, and unused code detracts from that characteristic.

• When deleted, author may feel uncomfortable

Author must get over it. We've all written things that turned out not to be useful - far better to be able to point to a body of code that is all being used (because the unused cruft was deleted) than to a body of code wherein you can say of a few methods, "and that one's actually in use!"

Answer 3

This discussion is several years old, but I just ran into it...

One thing that I did not see mentioned is the work that must be incurred to remove the unused code. In many cases, the time and effort to remove the unused code is not trivial in nature, plus there are typically additional costs to test and document the refactored system. Just another thing to consider in the decision process.

Answer 4

• Unused code is a bigger search space for both you to read through and anything else that generally scans your code. For example a compiler, IDE, find in file, debugging, static analysis, more to review, file inclusion, checking out from VCS, etc. This slows down those processes and adds significant noise.
• Unused code isn't always dead code. It may execute in certain circumstances. This can not only offer a vector for bugs and performance issues but can also be a security concern. In respect to performance this can express itself in unexpected ways such as larger downloads.
• Unused code begets unused code. If you delete a function call and then search for uses of that function to see if its still needed you might see a match from previous unused code and assume you can keep it. The more unused code you have the more hops it is to determine if code is unused.
• Unused code still often ends up having to be maintained. Lets say A and B depend on C. Out of those B isn't used. You change C and then B wont compile because you've removed a member from a struct in C that B required, now you have to fix B or actively remove it from compilation. You should have simply removed it.

This list might seem simple but each of these manifests in hundreds of different ways adding drag that synergises throughout the entire development process. The inefficiency can often be proven or demonstrated in a straight forward and mathematical manner.

In response to your points...

• Code is already written, and efforts are spent

But it often must be maintained. It will also show up still in things such as find in file.

• Code may be tested on syntetical and real environment

I'm not sure what you mean by this one. I think it's the same as the last one. You mean that the code is already tested and cleaning it up might mean it needs retesting. That's a cost that's usually worth it because it will pay off 90% of the time and to avoid that it should have been cleaned before going out into production. Nearly all code has two iterations, make it work, make it clean. The reason is has to be tested twice is because someone skipped the last step. If you code is also too expensive to proof read the diff, test (which it likely is if it's messy with lots of unused code), etc then that's another entire problem.

• If organized well (grouped, separate package, loosely coupled etc) it doesn't disturbs you on overall code analysis or refactoring

Your code should be like this anyway but that only moderately mitigates the problem. It's the strangest argument to hear that something should be organised yet unclean. It's normal to try to keep code modular and reduce dependencies but you also want reusable code and if all of your modules are an island chances are you've not been DRY. You may also find yourself doing excessive decoupling that does nothing but mitigates the problem of unused messy code.

• Code may be used in future

A lot of people over value written code. If it's not used now it's deadweight and in reality when you go down this path often only a fraction of unused code becomes used code. In all probability unused code is not likely to be usable or used code. The most likely to be reused code is already used code that's doing something.

What's worse is that unused code doesn't have a purpose. When someone comes along and has to change something that ends up impacting unused code they're going to be stumped sitting there trying to figure out what this unused code with no purpose needs to do.

It's easy for people to feel like this when starting out as code takes a lot of effort. Once fluent however and used to it code becomes like riding a bike. You'll find as the cost of writing such a piece of code plummets the cost of keeping it creeps up.

• When deleted, author may feel uncomfortable

This is the author's problem. On the one hand it is selfish to leave around loads of unused code for others to have to deal with. On the other if an author puts their feelings over code quality then they probably shouldn't be coding. You go down the road with this of you can't fix their code when it's broken because it'll hurt their feelings. It is not a good sign if someone is attached to code simply because it is theirs rather than because it is good. An author should feel happy at their code being cleaned. This is like someone taking out your trash for you and tossing it in the bin.

I would be over the moon if someone did that for me. What might make it easier to get over those feelings is instead of waiting for someone else to do it try doing it yourself. Keep iteratively rewriting a piece of code you've done, making it perform better, move concise, with less excess and more flexible yet with less code each time. Try not to feel good about the quantity of code but how much you can achieve with however little code. This is grinding to level up and once you do that all your code will come out at a good level following so it wont need to be leveled as often.

Answer 5

Dead code is polluting your code

Dead code decreases understandability and readability.

Best codes are always reused, and if u have dead codes it reduces reusability

We are driven by modular approach of coding, where we design codes for interaction with our fellow programmers, not for a machine. We should put the most energy to make it easy for he/she to understand our code. The machine will be fine anyway.

Dead or commented code is like false trail signs that only confuse people, so avoid it at all costs.