Dead Code
A code that is no longer executed or reachable in the current codebase.
Sign of Smell
In computer programming, the term "dead code" has multiple definitions. As a code smell, we can also refer to dead code as "unreachable code," which is code that can never be executed because there is no control flow path to reach it from the rest of the program. Dead code can also refer to code that is executed but has no effect on the final behavior or result.
At RubyConf 2019, Noah Matisoff discussed the topic of "Digging Up Code Graves in Ruby". He emphasized that dead code is a part of code hygiene, which in turn is a component of technical debt. Code hygiene encompasses various practices related to the health and longevity of a codebase.
Next, I will explain several types of dead code.
Unreachable code
The code that would never used, itβs out of the control flow path and unreachable from the rest of the program. Sometimes, you may encounter a situation where you have a conditional statement, but the conditions are always true or false. The unreachable code is hidden within a condition that will never occur.
Another common case is when you delete or refactor code, causing some parts to never be triggered after the change. However, during the code review, no one notices this.
Pointless Code
Pointless code refers to code that is executed or run but has no impact on the final result or behavior. It is also commonly known as dead code, but I am using a different name to avoid confusion here.
Feature Toggles
Feature toggles, also known as feature flags or feature switches, are a software development technique used to enable or disable specific features or functionalities in a software application without modifying the codebase. They provide a way to control the availability and behavior of specific features in a flexible and dynamic manner, often at runtime, rather than through static code changes or separate code branches.
However, if not managed carefully, feature toggles can introduce the "Dead Code" smell in your codebase. Martin Fowler, the author of "Refactoring", once shared his thoughts about Feature Toggles.
Savvy teams view their Feature Toggles as inventory which comes with a carrying cost, and work to keep that inventory as low as possible. β Martin Flower
It is a powerful design that is beneficial in most cases, but we should also be concerned about the code smell it might cause.
Reason of Smell
Readability: Unnecessary code clutters the codebase, reducing its overall readability. This can make it harder for developers to comprehend the code and can introduce noise that distracts from the actual functionality.
Code Bloat: Dead code increases the size of the codebase without adding any value. This can lead to larger binaries or longer download times for web applications, impacting user experience.
Potential Bugs: Dead code can hide real issues. If there are unused variables, functions, or blocks of code that were intended to be active, they might lead to unexpected behavior when changes are made elsewhere in the codebase. Developers may also mistakenly believe that unused code is still in use and could introduce bugs when they make changes.
Performance Overhead: Even though dead code is not executed, it still occupies memory and contributes to the size of the codebase. While this may not be a significant concern for small applications, it can impact performance and memory usage in larger or resource-constrained projects.
Maintainability: Dead code makes the codebase more challenging to maintain. Developers may waste time trying to understand and work with code that serves no purpose. It can lead to confusion and make it difficult to identify the relevant parts of the codebase.
Refactoring Recipes
Surprisingly, the "Dead Code" smell does not appear on the Smells to Refactorings Cheatsheet created by Joshua Kerievsky in 2005. However, we can still find some matching refactoring skills from other guidelines, such as the Refactoring Guru website.
Inline Class
Collapse Hierarchy
Remove Parameter
Dead code can refer to anything in our codebase - a variable, parameter, field, method, or even an entire class that is no longer used. Therefore, the skills required for refactoring also vary depending on the format of the dead code.
Inline Class
When we find that your class is doing almost nothing, we can definitely consider moving all the features from the class to another one.
Collapse Hierarchy
When we find that a class is doing very little and it is a subclass, we can merge it with its superclass.
Remove Parameter
When we notice that a parameter is not used, we should consider removing it.
Reference
Digging Up Code Graves in Ruby by Noah Matisoff at RubyConf 2019
https://en.wikipedia.org/wiki/Unreachable_code
Last updated