Dead Code Analysis

How to Detect Dead and Unreachable Code with Axivion Static Code Analysis

Axivion Static Code Analysis detects code that does not get executed based on the following types analyses:

Axivion Static Code Analysis finds dead functions by means of a reachability analysis on the call relation (i.e. the interprocedural control flow) of the analysed software. These functions will never be called and therefore will never be executed because there are no connections from the program entry points of the system (e.g. from main, interrupt handlers or callbacks) to these functions.

By means of deeper programme analyses, code areas within individual functions that are statically inaccessible and inaccessible in terms of programme logic, can also be found (unreachable code, dead code, infeasible paths, unreachable statements, redundant catch blocks). These analyses are used by corresponding coding guidelines, for example by the MISRA rules. A simple example is code directly after a return statement. Another example is an else branch, which can never be traversed due to the variable values occurring in the conditions involved. Infinite loops can also be detected.

Do Not Let Dead Code Obscure Your View

Code that will not be executed still needs attention. Dead code complicates comprehensibility, testability and maintainability. Special attention should therefore be paid to areas that “die” due to changes made to the code in the development process. Ask yourself:

  • Did this happen intentionally and can these lines of code be removed completely?
  • Will this code ever be needed?
  • Does this code need to be alive latest by the end of a sprint or development cycle?

Here, the delta analysis of Axivion Static Code Analysis comes into play. Through this direct feedback, preventive bug fixes and low-threshold refactorings can be guided precisely.



Are you building a library? Are you using interrupts?

A typical sticking point in dead code analysis concerns developers who develop libraries, frameworks or entire product families: In these cases the analysis can not be limited to a single application. Rather, for a complete analysis, the entire set of applications has to be given to the analysis in an appropriate setup. Depending on the context of the question about dead code, the “living” parts can therefore be specified by means of various configuration options. For example, APIs can be marked so that they are considered “alive” by the analysis.

By configuring the calling mechanisms of the operating system, the typical use cases can be simulated to take the interfaces into account accordingly during the analysis.

The configuration options are also useful for handling interrupt service routines and interrupt handlers. The corresponding functions for handling interrupts can already be marked as alive at the level of the programme code (keyword interrupt, use of attributes).

Do you code defensively?

The paradigm of defensive programming makes a lot of sense for the development of robust software, but often produces dead/unreachable code from the point of view of static analysis. Dead code as such is prohibited by the usual safety standards, as it often causes errors in the programming – nevertheless, these are code parts that you deliberately want to keep. Therefore, flexible configuration tools are available in Axivion Suite to “intentionally” mark dead code appropriately in the workflow and to take it into account accordingly in deviation management.

Seeing Is Believing

Contact us to discuss your specific use case with us and to schedule a demo.

Contact Us

Request a Demo

Contact Us

Download the Brochure


Success Stories

Read More

Axivion Static Code Analysis

Read More