The effects of redundant code

The false negatives and true positives can be collectively viewed as instances of YAGNI and raise
the following considerations:
 Bloated source
o In the past I’ve experienced text editors which couldn’t open large files.

o Developer cognition is limited by the number of independent entities that can be held

simultaneously in the brain. Usually this is taken to be seven so removing methods will lead to
better ability to reason.
o Any time taken by the developer to read and understand the source is most probably wasted.

o Modern IDEs typically create Abstract Syntax Trees from source so redundant code will slow
them down.
 Bloated executables

o This is particularly a problem for mobile phones where upgrades lead to the removal of apps so
as to free up storage, ultimately leading to having to upgrade the device when functionality is
too compromised.
 Bloated runtimes

o A greater attack surface for the hacker raises security concerns.

o Some applications for embedded devices allocate all dynamic memory at start so redundant
code will reduce the size of the available heap.
 Reduced performance

o In the specific case of dead code, execution will waste processor cycles.
 Reduced reliability

o In the specific case of dead code, execution may cause a crash.

 Reduced maintainability
o If the code unexpectedly stops being redundant then the behaviour is not predicted. e.g. Knight
Capital losing $440 million.
o The percentage of code coverage is potentially increased by false negatives and decreased by
false positives.
o Unnecessary tests will slow the execution of the test suite.

o Static analysis tools will have to process more and thus work more slowly.

o The design / architecture of the software appears more complicated than it actually is.

Given the wide variety of problems that may occur due to redundant code it is best to treat it as
a code smell.
 Management of existing redundant code
There are four ways of dealing with redundant code:

 Ignore it
o At least it will still compile although there is an associated maintenance cost.

o Not recommended.

 Automatic removal from executable

o If a compiled language use any dead code elimination option in the linker to remove it.
o If a dynamic language use tree shaking to eliminate at run-time.
o Again, not recommended.

 Block it out
o Either comment it out or use pre-compiler directives.

o Use code / comment folding in the IDE to avoid seeing it.

 Delete it
o Rely on source code control to keep the old copy for reference if you know to look for it and can
find it.
o Alternatively you may never need it again.

If the source code is going to be changed then any changes should be reviewed by someone
familiar with that section of the code to ensure that the code is really redundant.