Dead code and zombie code in development: what it is, causes and search

What is Dead Code?

Dead code is source code that is included in the program but is never executed under any usage scenario. The compiler or interpreter processes it, but at runtime, control never reaches these sections.

Classic examples of dead code: variables that are assigned a value but never read; functions or methods that are never called; conditional branches that never become true (if(false)); loops whose body never executes.

According to the SonarQube State of Code Quality (2025) report, about 15 percent of all warnings in commercial Java projects are related to unused private methods and fields. In JavaScript projects, the share of unused code can reach 30 percent due to the dynamic nature of the language and the abundance of third-party libraries.

Regularly check your project for dead code — especially after major refactorings and feature removals. One forgotten import or unused function today can turn into zombie code tomorrow, misleading new team members.

Dead Code vs Zombie Code Differences

Zombie code is a special case of dead code distinguished by its historical context. Zombie code once worked, but after changes in the system it became unreachable, yet it was not removed and was left “just in case.”

The difference between dead and zombie code lies in origin. Dead code might have been written erroneously (never worked), while zombie code is former live code that lost its relevance during refactoring. For example, a discount calculation function based on old business logic that was replaced by a new one, but the old method was not removed — in case it needs to be restored.

The main danger of zombie code is the illusion of working functionality. A new developer sees a function, reads its documentation, assumes it is called somewhere — and wastes time studying an artifact. When trying to call it directly, it may turn out that it depends on deleted entities or outdated APIs.

Track zombie code through git history: if a function has not been modified in two years and is not used — it is a zombie. Remove it without hesitation because git stores history, and the code can always be restored if needed.

Why Dead Code Appears

The first and most common reason is iterative development with incomplete refactoring. The team adds new functionality replacing the old one but does not remove the replaced modules. Sprints accumulate such “tails,” and after a year the project becomes overgrown with a layer of dead code.

The second reason is A/B testing and feature toggles. Conditions for enabling a new feature may become fixed over time (e.g., always true), but the else branch with alternative logic remains in the code. Developers are afraid to remove it in case they accidentally break the system if the toggle is switched back.

The third reason is code generation and copy-paste. Code generators (IDEs, template engines) create stubs with methods that the developer does not fill in or use. Code copied from another project often contains entire blocks irrelevant to the new context.

The fourth reason is fear of deletion. In large projects, developers are afraid to remove code because they are not sure it is really unused. This fear is exacerbated by a weak test system: without automated checks, deletion may lead to bugs that are only discovered in production.

Dangers of Dead Code

Dead code directly affects four aspects of project quality: build performance, artifact size, team cognitive load, and refactoring reliability.

Increased compilation time: the compiler processes unused files, analyzes dependencies, and generates bytecode or machine code for fragments that will never run. In large projects, this adds minutes to each build. For interpreted languages (JavaScript, Python), module loading time and memory consumption increase.

Risk of bugs during modification: a developer changing code does not suspect that a function is only used in a dead branch. After refactoring, the dead code stops compiling or produces errors — the team spends time diagnosing a problem that does not affect the application.

Cognitive load is the most expensive factor. Every unused function requires attention when reading code. A developer spends mental energy understanding why this code exists and where it is called. A Developer Productivity Lab study (2025) showed that removing 20 percent of dead code reduces onboarding time by an average of 18 percent.

Remove dead code immediately upon detection. Every day of delay increases the likelihood that someone on the team will spend hours studying an artifact that should have been removed yesterday.

Dead Code Detection Tools

Dead code detection is performed using two main methods: static analysis (without running the program) and dynamic analysis (runtime coverage profiling). Each approach is effective for different types of dead code.

Static analyzers support all popular programming languages. For Java and Kotlin — SonarQube, IntelliJ IDEA Inspections, SpotBugs. For JavaScript and TypeScript — ESLint with no-unused-vars and no-unused-modules rules. For Swift — SwiftLint with the unused_declaration rule. For Python — pylint with the unused-import option and vulture for deep search.

Example of searching in Kotlin via ProGuard

// build.gradle.kts - ProGuard configuration for Android
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro - keep only required classes
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard not only removes unused classes and methods but also minifies names in release builds. A build with ProGuard enabled automatically shows which classes and methods are considered unused — the usage.txt report lists all removed code.

Dynamic analysis via test coverage

Code coverage tools (JaCoCo for Java, XCTest coverage for Swift, Istanbul for JavaScript) show which lines and branches are executed during tests. Methods with zero coverage are candidates for dead code. However, lack of coverage does not guarantee the code is not called in production — for complete confidence, use a combination of static and dynamic analysis.

Configure your CI pipeline so that the build fails when the threshold of unused declarations is exceeded. A SonarQube Quality Gate with the rule “Share of unused private code no more than 3%” prevents dead code accumulation at the development process level.

How to Safely Remove Dead Code

The process of removing dead code consists of four steps: find, verify, delete, verify again. Skipping any step increases the risk of regression.

The first step — find candidates via a static analyzer. Get a report of unused declarations: functions, classes, variables, imports. Filter out false positives — analyzers sometimes make mistakes with reflection, dynamic class loading, or hidden calls via serialization.

The second step — check via git blame and change history. Look at when and why the code was written. If the code was part of a feature disabled by a feature toggle — make sure the toggle is fixed and will not be turned back on. Comment out code you are unsure about removing and leave a TODO with a ticket for re-checking in a month.

The third step — delete in a separate branch and run the full test suite. If tests pass — the likelihood of regression is low. If tests fail — the code is still used, and you need to figure out in which scenario.

// before - dead code and zombie code in same file
int calculateV1(int price) { // not called anywhere
    int tax = price * 0.18;
    return price + tax;
}

int calculateV2(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

// after - dead code removed, zombie code cleaned
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

The fourth step — code review of changes. The reviewer must confirm that the code is indeed dead. If the reviewer is not sure — leave a comment in the code and postpone deletion until a full analysis. After merging the branch — delete the branch to avoid proliferating zombie code in the git repository.

Adopt a rule: no pull request should introduce new dead code. Add a linter to pre-commit hooks that blocks commits with unused variables or imports. Prevention is always cheaper than cleanup.