Cross-platform software libraries and APIs
Qt Creator IDE and productivity tools
UI Design tool for UI composition
for Qt projects
Digital advertising for UI apps
Usage intelligence for embedded devices
GUI test automation
Code coverage analysis
Test results management and analysis
Software static code analysis
Software architecture verification
The latest version of Qt.
Make the most of Qt tools, with options for commercial licensing, subscriptions, or open-source.
Explore Qt features, the Framework essentials, modules, tools & add-ons.
The project offers PySide6 - the official Python bindings that enhance Python applications.
Qt empowers productivity across the entire product development lifecycle, from UI design and software development to quality assurance and deployment. Find the solution that best suits your needs.
Insight into the evolution and importance of user-centric trends and strategies.
Learn how to shorten development times, improve user experience, and deploy anywhere.
Tips on efficient development, software architecture, and boosting team happiness.
Get the latest resources, check out upcoming events, and see who’s innovating with Qt.
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.
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:
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.
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).
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.