Dead code

from Wikipedia, the free encyclopedia

Dead Code ( English dead code ) is in the programming a term for parts of a computer program "are used at any point in the program". In a broader sense, dead code can be viewed as a special form of redundant code (= “superfluous”). Dead code can contain instructions / commands or refer to unused data declarations .

Unreachable code is a part of the program that cannot be reached by any possible control flow and therefore cannot even be executed; Here, too, one speaks of dead code.

meaning

All forms of dead code are considered undesirable or lacking in software quality for various reasons .

Depending on the situation, dead code can also arise deliberately: It should, for example, preserve a provisional or former part of the source code. Often, however, there is also a program error, the detection of which is a goal during software testing.

Although the results of dead code are never used, it can throw exception handling or affect global states. A code change can change the program output and cause unintentional program errors. It is controversial whether these cases are still dead code.

example

1 int foo (int x) {
2   int y = 100 / x;  // toter Code, da y nicht verwendet wird
3   int z = x * x;    // redundanter Code zu 2 Zeilen weiter unten
4   if (z >= 0) {     // unnoetiger Code, da die Abfrage immer wahr ist
5     return x * x;   // redundanter Code zu 2 Zeilen weiter oben
6   }
7   return -1;        // unerreichbarer Code, da z immer >= 0 ist
8 }
  • Dead Code - In the example, the number 100 is xdivided by in line 2 , but the result is never used. It is therefore dead code. However, if x is zero , an exception is thrown. Removing this code leads to a change in functionality. Since raising exceptions should never be part of the functionality, it is a faulty functionality that must be removed.
  • Redundant code - In the example, xlines 3 and 5 are squared without changing anything in xbetween. The result is always the same, so the code is redundant. return zwould therefore be appropriate in line 5.
  • Unreachable code - In the example, line 7 is never reached because the query z >= 0in line 4 is always true and the method is exited in line 5. Line 7 is therefore unreachable code.
  • Unnecessary Code - Since the query z >= 0on line 4 is always true, it is pointless and can be removed as well. Unnecessary code does not fall into any of the three categories mentioned, but is commonly referred to as dead code.

reasons

Dead code can arise from among other things

  • Programming error; in the case of (still) incomplete testing of a new or changed program;
  • a new bug that was inadvertently added by a programmer while a bug was being corrected, bypassing the unreachable code and going undetected during testing;
  • redundant code that a programmer did not want to remove because it was mixed up with functional code;
  • redundant code that a programmer forgot to erase;
  • Previously meaningful code that can never be accessed because the input data has changed, so that this code is never called again;
  • complex, redundant code that has purposely not been removed but made inaccessible so that it can be "revived" if necessary;
  • Defect-locating constructs ( Eng. debugging constructs ) and remnants of development code that still has to be removed from the program.

In the last five cases, the currently unreachable code is a legacy; H. Code that used to make sense but is no longer needed.

example

Often dead code is intentionally created in order to disable output later during program development:

int main()
{
#define DEBUG  0
    int a = 3;
    // ...
    if (DEBUG)
        printf("%d\n", a);
    // ...
    return a;
}

During the development phase, the value of the variable a can be output here if the DEBUG macro is set to a value not equal to zero (true). If this control output is no longer required, the value is set to 0 and the preprocessor recognizes and removes the now dead piece of code.

analysis

Detecting dead code is a form of static code analysis and requires a detailed control flow analysis to find the code regardless of the variables and other runtime conditions. With the help of suitable analysis tools, a large number of dead and inaccessible code parts can be found. In some languages ​​(such as Java ), some forms of inaccessible code are expressly prohibited and lead to compilation errors.

In large software projects, it is sometimes difficult to detect and remove dead code, especially when entire modules are affected. The test framework can show such code as still "alive", and it can even be that the irrelevant code has to be delivered for contractual reasons.

In some cases, a practical, not overly burdensome approach is a combination of simple unreachability criteria and the use of a profiler to handle complex cases. Profiling cannot prove the inaccessibility of code . But it is a good heuristic method for discovering potentially inaccessible code. If a piece of code is seen as suspicious, other methods such as For example, more efficient code analysis tools can be used or the analysis can be done manually. This allows you to decide whether the part of the code found is really inaccessible or not.

optimization

Since the mid-1990s, it has been the state of the art for compilers and linkers to recognize and remove unused sections of code. This optimization technique is known as dead code elimination . Since the mid-2010s, equivalent techniques have found their way into IDEs (display of unused code while editing) and in debuggers (code that can no longer be reached in the current run, for example, is darkened).

The correct, redundancy-free implementation of the above example would look like this:

1 int foo (int x) {
2     return x*x;
3 }

The optimization of dead codes works in a similar way for all types of dead codes, mostly by simply removing the relevant code positions. Particular care should be taken when removing dead code, as dead code can have side effects that cannot be seen in the code itself.

Compiler optimizations are typically conservative approaches to removing dead or unreachable code. If there is an ambiguity regarding program behavior, the code is not removed. Optimization during compilation is called dead code elimination . It can be done for dead code through variable analysis , for inaccessible code with data flow control.

The code can also become inaccessible due to transformations that the compiler performs , such as: B. the so-called common subexpression elimination (removal of common subexpressions).

In practice, the sophistication of the analysis has a decisive influence on the proportion of unreachable code that is found. For example, constant folding and simple flow analysis can show that the function call foo()in the following example is inaccessible :

int i = 2 + 1;

if (i == 4)
   foo();

However, there are theoretical limits to a complete analysis at compile time, which are closely related to the decidability problem of theoretical computer science.

public perception

In November 2010, Microsoft released a new version of Internet Explorer , which apparently left all other browsers far behind in terms of JavaScript speed. It soon turned out, however, that Microsoft was using a special implementation of dead code elimination to catapult itself to the top of a well-known JavaScript benchmark . In other benchmarks, the results were more in the middle.

literature

  • SS Muchnick: Advanced Compiler Design and Implementation . Morgan Kaufmann, 1997.

Web links

  • DCD Alternative comparison of different tools for static code analysis with functionalities for finding dead codes

Tools to find dead / unreachable codes

Individual evidence

  1. Fernuni Hagen: An Eclipse plugin to track down dead code fragments (...) , PDF.
  2. ^ Douglas W. Jones: Dead Code Maintenance . ( Memento of the original from July 8, 2011 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Risks 8.19, February 1, 1989 @1@ 2Template: Webachiv / IABot / catless.com
  3. Herbert Braun: Browser Debate: Has Microsoft Cheated? Heise Online, November 18, 2010.