Unreachable code

In computer programming, unreachable code is part of the source code of a program which can never be executed because there exists no control flow path to the code from the rest of the program.^[1]

Unreachable code is sometimes also called dead code,^[2]^[3] although dead code may also refer to code that is executed but has no effect on the output of a program.^[4]

Unreachable code is generally considered undesirable for several reasons:

It uses memory unnecessarily
It can cause unnecessary use of the CPU's instruction cache
- This can also decrease data locality
Time and effort may be spent testing, maintaining and documenting code which is never used
- Sometimes an automated test is the only thing using the code.

Unreachable code can have some legitimate uses, like providing a library of functions for calling or jumping to manually via a debugger while the program is halted after a breakpoint. This is particularly useful for examining and pretty-printing the internal state of the program. It may make sense to have such code in the shipped product, so that a developer can attach a debugger to a client's running instance.

^ Debray, Saumya K.; Evans, William; Muth, Robert; De Sutter, Bjorn (1 March 2000). "Compiler techniques for code compaction". ACM Transactions on Programming Languages and Systems. 22 (2): 378–415. CiteSeerX 10.1.1.43.7215. doi:10.1145/349214.349233. S2CID 6129772.
^ RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification. RTCA, Inc. 2011. p. 112. Retrieved 2019-06-11. Dead code – Executable Object Code (or data) which exists as a result of a software development error but cannot be executed (code) or used (data) in any operational configuration of the target computer environment. It is not traceable to a system or software requirement. The following exceptions are often mistakenly categorized as dead code but are necessary for implementation of the requirements/design: embedded identifiers, defensive programming structures to improve robustness, and deactivated code such as unused library functions. [Since requirements-based review should identified such code as untraceable to functional requirements, static code analysis should identify such code as unreachable, and structural coverage analysis of requirements-based testing results should identify such code as unreachable, presence of unjustified dead code in a project should raise consideration of the effectiveness of the organization's development and verification processes.]
^ Jay Thomas (24 January 2017). "Requirements Traceability Forms the Foundation for Thorough Software Testing". Retrieved 2019-06-11. The combination of requirements traceability with coverage analysis can also turn up areas of "dead code," or code that's never executed. This code can mostly be an inconvenience, but it can also be a security threat if a hacker can gain access and from there gain control. It's code that can't be traced and should therefore be eliminated.
^ MISRA Consortium (March 2013). MISRA C:2012 Guidelines for the used of C language in critical systems. MIRA Limited. p. 41. Retrieved 2019-06-11. Rule 2.2 there shall be no dead code. Any operation that is executed but whose removal would not affect program behavior constitutes dead code.

[1] Debray, Saumya K.; Evans, William; Muth, Robert; De Sutter, Bjorn (1 March 2000). "Compiler techniques for code compaction". ACM Transactions on Programming Languages and Systems. 22 (2): 378–415. CiteSeerX 10.1.1.43.7215. doi:10.1145/349214.349233. S2CID 6129772.

[2] RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification. RTCA, Inc. 2011. p. 112. Retrieved 2019-06-11. Dead code – Executable Object Code (or data) which exists as a result of a software development error but cannot be executed (code) or used (data) in any operational configuration of the target computer environment. It is not traceable to a system or software requirement. The following exceptions are often mistakenly categorized as dead code but are necessary for implementation of the requirements/design: embedded identifiers, defensive programming structures to improve robustness, and deactivated code such as unused library functions. [Since requirements-based review should identified such code as untraceable to functional requirements, static code analysis should identify such code as unreachable, and structural coverage analysis of requirements-based testing results should identify such code as unreachable, presence of unjustified dead code in a project should raise consideration of the effectiveness of the organization's development and verification processes.]

[3] Jay Thomas (24 January 2017). "Requirements Traceability Forms the Foundation for Thorough Software Testing". Retrieved 2019-06-11. The combination of requirements traceability with coverage analysis can also turn up areas of "dead code," or code that's never executed. This code can mostly be an inconvenience, but it can also be a security threat if a hacker can gain access and from there gain control. It's code that can't be traced and should therefore be eliminated.

[4] MISRA Consortium (March 2013). MISRA C:2012 Guidelines for the used of C language in critical systems. MIRA Limited. p. 41. Retrieved 2019-06-11. Rule 2.2 there shall be no dead code. Any operation that is executed but whose removal would not affect program behavior constitutes dead code.

[1]

[2]

[3]

[4]