The risks of redundant code (or - Less is More)

One of the preferred refactoring methods of my choice is deleting redundant code.

I separate between excessive code and redundant code:

1. Redundant code is code that never runs:

• Unreachable code
• Unused classes, interfaces and methods
• Commented-out code
• Code that looks wrong, then you understand that it is indeed wrong, but is being lucky enough not to be called
• Code that deals with cases that cannot happen
• Code that deals with cases that could happen in the past, but now cannot
• Code that is there for future cases, which are not occuring yet (and may be added sometime)

2. Excessive code is code that runs, but can be reorganized into less lines of code:

• Unnecessary abstractions, unneeded levels of delegations
• Copy-Paste that can be moved to methods, inheritance, templates

Both are bad and should be treated. But the first category, redundant code, is much riskier. The main risk of redundant code is that it looks innocent and useful, but it doesn't really work and it is never tested. In many cases you assume that there is some value in this code, so you keep it around, maybe it will become useful sometime. Well, most probably it will become useful by creating new bugs when you accidentally use it. Remember: this code was never really tested, just being there, so familiar, part of your code, does not make it something that works. And in many cases it confuses you, as you believe that a feature is already written, because the code is there, you only need to pass another value or take some code out of a comment. But this code was not maintained or tested for ages, if at all! How can you rely on it? Why keep it there in the first place?

My recommendation usually is to be very cautious with code that never ran and is just lying there, as it may be lying and not doing what it supposed to do.

Keeping unnecessary code requires you also to maintain these lines of code that you don't really need. Again, I say - get rid of it.