Editing Unreachable code (section)

{{Short description|Section of code in a program that can never be executed}}
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.<ref>{{cite journal|last1=Debray|first1=Saumya K.|last2=Evans|first2=William|last3=Muth|first3=Robert|last4=De Sutter|first4=Bjorn|title=Compiler techniques for code compaction|journal=ACM Transactions on Programming Languages and Systems|date=1 March 2000|volume=22|issue=2|pages=378–415|doi=10.1145/349214.349233|citeseerx=10.1.1.43.7215|s2cid=6129772}}</ref>

Unreachable code is sometimes also called ''dead code'',<ref>{{cite book
 | title       = RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification
 | publisher   = [[Radio Technical Commission for Aeronautics|RTCA, Inc.]]
 | year        = 2011
 | url         = https://my.rtca.org/NC__Product?id=a1B36000001IcmqEAC
 | page        = 112
 | quote       = 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.]
 |access-date = 2019-06-11  }}</ref><ref>{{cite web |author= Jay Thomas |title= Requirements Traceability Forms the Foundation for Thorough Software Testing |date= 24 January 2017 |quote= 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. |url= https://ldra.com/requirements-traceability-forms-foundation-thorough-software-testing/ |access-date = 2019-06-11 }}</ref> although [[dead code]] may also refer to code that is executed but has no effect on the output of a program.<ref>{{cite book |author= MISRA Consortium |title= MISRA C:2012 Guidelines for the used of C language in critical systems |date= March 2013 |publisher= [[MIRA Ltd.|MIRA Limited]] |url= https://www.misra.org.uk/Activities/MISRAC/tabid/160/Default.aspx |page= 41 |quote= 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''. |access-date = 2019-06-11 }}</ref>

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.