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

Question

Here are some reasons why unused code should be removed:

• For anyone new working on a project, they not only have to understand the working code, they have to understand unused material also. This is wasted time and creates confusion.

• There is a danger that at sometime someone will make a change which inadvertently involve the 'dormant' code and can introduce bugs. I know it's happened on projects I've worked on.

• The maintenance of any code is an administrative burden. By preserving old redundant code that burden is increased. For example, merging changes in the main branch becomes harder because there is more code to work through and more possibility to make a mistake.

• What happens over time is that more and more old unused code is added to the codebase. This increases the confusion, potential misunderstanding and administrative overhead.

• The chances that the unused code will ever be used again is very unlikely. With time that possibility of re-use diminishes. If code is to be removed and is considered important enough then the code can be branched off and documented.

• Any personal feelings that a coder may have about code they may have worked hard on are understandable. But part of being professional requires that those thoughts have to be put to one side for the better good. Time stands for no-one and there is no place for preserving historical code in a working codebase.

@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!"

Isn't it tough enough to pick up some code and figure out the intent, but now you have to figure out which parts are not in use?

Code is already written, and efforts are spent

It is also unnecessary. If you do not use it for anything, it is (by definition) useless, regardless what it does or how much effort was spent on it.

Code may be tested on syntetical and real environment

If it's useless, it is still useless even if you have tests on it. If the code is useless, the tests for it should useless as well (so keeping the commented code there, creates ambiguity - do you keep the tests? if you had client code of the commented code, do you comment the client code as well?)

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

Not so. All your tools (source control, static analysis, documentation extractor, compiler, etc) will run slower, because they have to process more data (and a bigger or smaller part of that data is noise).

If the code is not organized well on the other hand, it will mess up static analysis, refactoring, and any others.

You're introducing noise to your tools input and hoping they cope correctly with it.

What if your static analysis tool computes a comments/code ratio? You just messed it up, with something that was relevant up until yesterday (or whenever the code was commented).

Most relevant of all, commented blocks of code introduce delays in understanding the code for maintenance and further development and such delays almost always cost a lot. Ask yourself this: If you need to understand the implementation of a function, what would you rather have to look at? two lines of clear code, or two lines of code and another twenty-six of comments that are no longer actual?

Code may be used in future

If it is, you will find it in your team's SCM of choice.

If you use a competent SCM and rely on it to keep the dead code (instead of cluttering up the source), you should see not only who deleted that code (commit author), but for what reason (commit message), and what other changes were made along with it (the rest of the diffs for that commit).

When deleted, author may feel uncomfortable

So?

You are (I assume) an entire team of developers that gets payed to make the best software you know how to, not "the best software you know how to without hurting the feelings of X".

It's a part of programming, that most code written will ultimately be discarded; for example, Joel Spolsky said at some point that for his company, approximately 2% of written code sees production.

If you prioritize the ego of developers over the quality of the code base, you will sacrifice the quality of your product, for ... what exactly? Preserving the immaturity of your fellow developers? Protecting the unrealistic expectations of your colleagues?

Edit: I have seen one valid reason to leave commented out code in the source, and it is a very specific case: when the code is written in a weird/un-intuitive form and the clean way of re-writing it doesn't work for a really subtle reason. This should also be applied only after a repeated attempt has been made to correct the issue and every time the attempt has re-introduced the same defect. In such a case, you should add the commented intuitive code as a comment, and explain why it doesn't work (so future developers will not attempt the same change again):

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

• Fear. This makes the team worry more and produce less. The amount of fear goes up exponentially when more dead code is introduced. "We don't know if that bit is used, so we don't dare remove it or touch it."

• Sweeping changes. If something that needs to be changed everywhere in the system also exists in the dead code, do you change it? It's very hard to know if it is definitely not used somewhere, so it's always a risk. And even if it wouldn't break anything, would the dead code work at all if it would be taken back to use after this change?

  When dealing with a sweeping change the developers will also have to check every place that contains the code and in the case of dead code this is redundant. And checking them takes longer when the code's dead since it's hard to verify that it isn't used anywhere.

• Mental load. Everytime you need to think about whether something is used or whether you should do something to the dead code, it takes some of your brain power.
• Wild goose chases. "I need an example on how to use Foobar. Oh it's in these places in the codebase. I'll check the first hit and find out where this is in the UI. Hmm... Can't find it anywhere."
• Inflated reports (e.g. how many lines of code, classes, routines, changes). Distorts visibility of the project and decisions on what parts of the codebase should be worked on and estimations of future projects.
• Weakened trust on the codebase. This can result in more time spent on redundant tasks and it breaks the flow of using the codebase. Developers might have to check extremely carefully that everything they use will work in the way they think it should.

It is extremely valuable if you know that a part of the codebase is not used because then you can remove it. If you let it stay then in the future it can be hard or almost impossible to be certain that it is actually not used. For example, some of the things that use code in surprising ways: reflection, dynamically calling routines concatenated from strings, eval, framework magic.

However, if there is a high probability that code will be used in the future, it is easier to add if it's right there along the other code instead of in the version control system. You might not remember any words that the code had after a while so it can be very hard to find the code from the bowels of the VCS. But I'd let dead code exist only rarely and even then I'd comment the code out.

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.

• 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.