A new term appears in the structural coverage analysis resolution section (§220.127.116.11): Extraneous code, which is an extension of “dead code”. The idea is to consider all code (or data) that is the result on an error, whatever this code may be or not exercised. The definition of dead code is limited to the executable object code that cannot be exercised. Extraneous code includes dead code, but also all pieces of code, found at source or object code level, that may be exercised or not.
The fundamental idea remains unchanged. This code, executable or not, should be removed. However, it is now allowed to keep this code as long as it is demonstrated that (1) this extraneous code does not exist in the executable object code, and (2) procedures exist to prevent their inclusion in future software releases.
Here is the definition of “extraneous code” and the new definition of “dead code” providing more examples on exceptions:
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.
Extraneous code – Code (or data) that is not traceable to any system or software requirement. An example of extraneous code is legacy code that was incorrectly retained although its requirements and test cases were removed. Another example of extraneous code is dead code.