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

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);

Answer 2

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

Answer 3

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.

Answer 4

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?

Answer 5

Are you sure the code is unused?

It's not enough to check the code still compiles. In C++, if you remove an "unused" implicitly defined method like operator= you're not going to get a compiler error, the class will just silently begin to use a (potentially incorrect) default implementation. 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.

Aggressively remove unused code

You pay to maintain code:

• Fixing broken builds (engineering time). We recently had a complicated chain of #include change, introducing a new overload to unused code, leading to a reasonably-sized headache for every engineer on a team of dozens of developers.
• In machine resources on tests (assuming you have self-testing continuous builds). My team recently looked at all of our slowest tests, and many of them were over otherwise unused code. Engineers running tests locally or as part of continuous integration are waiting for tests over unused code.
• In terms of readability (engineering time again). Your header files represent an API. If they include functions no one would want to use but everyone has to read, your code's learning curve is that much harder.
• In code searches (engineering time again). Would you clean up your house, your hard drive, or Google Drive? The more you search a domain, the more important it is for it to have relevant content to avoid false positives (or you use more sophisticated search like a web search engine).

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.

Answer 6

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