You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

8.19 - Dead / Dormant Code and Safety Critical Software

1. Introduction

This topic discusses the issues of having dead or dormant code in software that is safety critical. 

1.1 What is Dead Code or Dormant Code?


  • Code, definition, function or configuration that is never used during runtime.
  • Section of source code that is executed, but the result is never used.
  • Logic branch that is unreachable or can never be executed under current configuration
  • Configuration items that are no longer called or utilized.
  • Summation: Dead/Dormant code is:
    • Code that is not executed.
    • Function that is not used.
    • Configuration that is not used.
    • A result of a function that is never used.

Note: Dead and Dormant code are, in this respect, considered fundamentally the same thing.
For the remainder of this topic, “Dead” code will be used to refer to both “Dead” and “Dormant” code.

1.2 Why are Dead Code and Dormant Code problems?

Potential problems with Dead/Dormant Code:

  • Makes the Code Base harder to understand and maintain (Increases cost and time)
  • Increases inefficiency of the system.
  • Increases potential instability and thus increases risk.
  • Results in a greater chance for unexpected or undesired result.

1.3 What are the best practices to use with Dead/Dormant Code?

What should be done to minimize Dead Code?

  • Dead code should be identified. Comment statements might be one way to identify the Dead code.
  • Dead code should be removed if possible.
  • Avoid duplication of code or functions. This leads to Dead code as well as increased difficulties in maintaining the Code Base. If portions of the code will be used multiple times, put them in a function that can be called.
  • If available, use analysis tools for identifying Dead code. These tools are separate from compilers. Some compilers identify the Dead code and don’t put it into the executable, but that still leaves the Dead code in the Code Base that is being maintained.
  • Ensure 100% code coverage for unit testing. This will help to determine if any Dead code exists. If 100% coverage cannot be achieved, determine and document why and determine the potential risk.

General Guidelines and best practices to manage Dead Code.

  • Avoid duplication of code or functions. This often leads to Dead code during future code modifications.
  • When using a compiled language, do not depend on the compiler to remove any Dead code. Any identified Dead code should be actively removed before the compilation.
  • Use a Code Analysis tool to identify Dead code.
  • Avoid using test or temporary code inside the Code Base. This includes all code that is not directly needed for operation in a live environment. If using test code within the code base is required for testing purposes, it must be removed before the code base is released.
  • Verify configuration items are documented and utilized. If not utilized, they should be removed.
  • Each development team should have established procedures for identifying, handling and removing Dead code. These procedures should be tailored to the needs of each team to facilitate requirements and ensuring stable and reliable code.
  • Before removing Dead code, ensure it is not being utilized by other processes. This is especially important in software that is used between multiple projects and purposes.

For more discussion and some examples, see  the Dead Code Exclusion in the Software Design Principles tab.

2. Resources

2.1 References

No references have been currently identified for this Topic. If you wish to suggest a reference, please leave a comment below.

2.2 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN). 

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN. 

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool.  The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

  • No labels