In control flow analysis, unreachable code is one or more statements that, by a set of simple rules, can be proven to be unreachable, that is, they will never be executed regardless of the values of variables and other conditions at run time. Control flow analysis is often used as a step in the compiling of modern languages, and in some languages (e.g. Java or C#), unreachable code is explicitly disallowed.

Sources

In languages such as C++ that allow unreachable code, such code may result from a common programmer practice to temporarily disable code at the tail end of a loop with a break or continue statement. For example, if in the following code:

while (condition) {
  do this
  do that
}

we wish to temporarily disable the functionality of do that (possibly several lines of code), a quick hack would be:

while (condition) {
  do this
  continue;
  do that
}

In this example, do that has become unreachable code. Unfortunately, sometimes changes that are intended as temporary often make their way into the release version.

Other sources of unreachable code include redundant checking of exception conditions.

Consequences

Unreachable code creates unnecessary work for the compiler and may result in code bloat .

True vs. rule-based unreachability

Rules for deciding unreachability are chosen so that rule-based unreachability is a sufficient condition for true unreachability, that is, if the rules say a statement is unreachable, then it can be proven mathematically that the statement is truly unreachable. On the other hand, it is infeasible to choose rules that are equivalent to true unreachability. This problem exists for a number of reasons.

First, it is most convenient evaluate reachability in the smallest scope as possible. Often, this is on the function/method level, although sometimes an even smaller scope, such as the innermost enclosing control structure, is used. Because reachability must be evaluated for each statement in a program, failing to adequately limit the scope can result in a severe performance penalty.

Second, even on a local level, many types of seemingly good reachability criteria can be arbitrarily complex. For example, it may seem like a good idea to consider statement xyz in the following code unreachable:

int n = 2 + 1;
if (n == 4) {
  xyz
}

However, it is easy to find analogous examples where this type of criterion is inappropriate. For example, in the following code:

double x = sqrt(2);
if (x > 2) {
  xyz
}

statement xyz is truly unreachable, but to discover this at compile time imposes unnecessary conditions on the compiler. To maintain consistency in the rules and avoid confusing programmers, the unreachability rules used by compilers generally avoid these complicated cases. However, tools aimed primarily at code analysis may take such cases into account.

Unreachability vs. profiling

In many cases, the most practical approach may be a combination of simple unreachability criteria and use of a profiler to handle the more complex cases. Profiling in general can not prove anything about the unreachability of a piece of code, but is a good heuristic for finding potentially unreachable code. Once a suspect piece of code is found, other methods, such as a more powerful code analysis tool, or even analysis by hand, could be used to decide whether or not the code is truly unreachable.