Why remove unused code

Runtime monitoring of the system cannot definitively tell you which parts are dead, but they can tell you which parts are definitely alive. This helps you narrow the search. Deleting dead code is not a technical problem; it is a problem of mindset and culture. Let the version control system remember it for you. There are many reasons to remove dead code, not just the possibility of a zombie apocalypse.

Dead code makes the runtime footprint larger than it needs to be. If you care about performance, then care about performance. Dead code is an obstacle to programmer understanding and action; bulking out a system with dead code wastes developer time and discourages a culture of treating the software as soft, and therefore always open to revision and improvement.

InfoQ: You also talk about problems with code that is not dead, but is often neglected and almost left for dead: error-handling code. How can incorrectly handling non-fatal errors lead to catastrophic failures? Henney : The more a piece of code is used, the more likely it is that its bugs will have been revealed and fixed. Error-handling code is often some of the least well-explored code in a system. Many error cases are rare edge cases, so although code is present to handle them, the correctness of the code is unproven.

Sometimes quite literally, as was the case with the loss of the first Ariane 5 rocket in InfoQ: What advice can you offer for dealing with error conditions and exceptions?

Henney : Reviews, static analysis and automated tests. Walking and talking through can help reveal oversights and generate new questions and awareness. Depending on the language, you can get some helpful feedback from tools about what might happen at runtime. Testing is one way to be sure that a piece of code is executed in a safe environment, although keep in mind that people often have a blind spot and optimism bias where error-handling code is concerned, testing only the happy-day scenarios.

To address this, always ask: If an error condition is signalled, where is the corresponding handling code? Where is the test for the error condition? And where is the test for the handling code? Get total control of your code to ship fast, reduce risk, and reclaim your nights and weekends.

Book a demo today! Join a community of over , senior developers. View an example. You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered. Your message is awaiting moderation. Thank you for participating in the discussion. I would think this is applicable for systems of strategic importance. For most of the other systems in large IT organizations, The cost of remediation - effort involved in finding, deleting dead code and testing - is very high.

The first step is to assess whether or not a system is of strategic importance. Because they are interconnected, most systems in an organisation should be considered strategic. As many failures in the industry have demonstrated, subtle causes reveal many "non-strategic" systems are more critical than they first appear.

The programmer invented extra requirements that were not documented in the story that justified the extra feature. The requirement was actually bogus. Hint: Programmers do not set system requirements; the customer does.

Now, we had a well-understood lean development process, very good developers, and procedural checks in place to avoid this kind of thing. And unnecessary extra code still snuck in. Even if you can avoid adding unnecessary new features, dead pieces of code will still spring up naturally during your software development. They come from a number of unavoidable accidental sources, including:. Instant code necrosis. Data types or classes that are no longer being used tend to stay put in the project.

You can also render parts of a class obsolete: for example, reworking methods so a member variable is no longer needed.

Legacy product features are rarely removed. Even if your users no longer want them and will never use them again, removing product features never looks good. It would put a dent in the awesome list of tick-box features. So we incur perpetual product testing overhead for features that will never be used again. The maintenance of code over its lifetime causes sections of a function to not be executable.

Loops may never iterate because code added above them negates an invariant, or conditional code blocks are never entered. The older a codebase gets, the more of this we see. C helpfully provides the preprocessor as a rich mechanism for writing non-executable spaghetti. Wizard-generated UI code inserts hooks that are frequently never used. If a developer accidentally double-clicks on a control, the wizard adds backend code, but the programmer never goes anywhere near the implementation.

Many function return values are never used. But many functions are written to do something and return a result that someone might find useful. Or might not. 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. 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. 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. 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. 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. 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. 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 :.

I think that you can have two cases: - application code : if it unused maybe it is untested and unmantained over the time, maybe you can shift to a "internal code repository" - API code : if you are writing a library then IMHO it's a better choice to maintains it but inside your active development process. It's not enough to check the code still compiles. In Java or C the code might be used via reflection.

In object-oriented languages, inheritance can play a role the base class may now be called. In almost any language, another overloaded function may have taken over. Check the age of the code in version control, not just that it's unused. I've seen code that looked unused but had just been committed, and was actually the first step in another developer's project. I'd say essentially all the code the average developer writes becomes unused on a five year horizon so this activity never stops.

Don't let this be you; only write high quality and absolutely necessary code. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Could someone explain the pros of deleting or keeping unused code?

Ask Question. Asked 8 years, 7 months ago. Active 2 years, 2 months ago. Viewed 29k times. My points for not deleting that are: Code is already written, and efforts are spent Code may be tested on syntetical and real environment If organized well grouped, separate package, loosely coupled etc it doesn't disturbs you on overall code analysis or refactoring Code may be used in future When deleted, author may feel uncomfortable Could someone explain the pros of deleting or keeping unused code?

When I work with IT management in my capacity as a consultant, I encourage them to view code differently. I encourage them to view code as a liability, like inventory. And when useful code is a liability, think of what a boat anchor dead code is. I once wrote a fun post about the fate of dead code in your codebase. And while I enjoyed writing that, it had a serious underlying message.

Dead code costs you time, money, and maintenance headaches. And it has absolutely no upside. How does it cost time and money, as I claimed a moment ago? Well, simply put, your code does not live in a shrink-wrapped vacuum. As your application evolves, developers have to change the code.

When you have only code that matters in your codebase, they can do this with the most efficiency. If, on the other hand, you have thousands of lines of useless code, these developers will spend hundreds of hours maintaining that useless code. Think of having dead code as being reminiscent of running your heat in the winter while keeping all of your windows open. This happens when you take a chunk of code and comment all of it out, like this:.

I think this comes about for a couple of reasons. First, some folks carry this kind of thing forward from before the days of ubiquitous source control. They leave it in as a historical reference.

Secondly, people comment out an implementation to experiment with another and then forget to remove the commented code. Whatever the reason, your course of action is simple.