5.1.3. Issue Kinds

The Axivion Suite detects issues of six kinds. Each issue kind is associated with an icon and a 2-letter abbreviation used to refer to a concrete issue kind in the Dashboard API. In the following, the six issue kinds are listed with their icons, abbreviation, and a brief description.

The analysis is highly configurable, so the issues found by the analysis depend on the configuration. Therefore, you might only see a subset of the issue kinds in your analysis results.

Architecture Violation AV

An Architecture Violation is an inconsistency between your architecture model and your implementation, i.e., the source code. There are two flavors: A divergence shows that there is a hidden dependency in the code that is not modeled in the architecture. An absence shows that there is a dependency in the architecture model that is not used by any dependency in the source code. The architecture is the foundation of your system needed for designing, implementing, onboarding of new colleagues, and planning and discussing changes to the system. Therefore, each architecture violation adds a penalty in the central activities of software development.

Clone CL

A clone consists of two regions in the source code that are similar. A type 1 clone is an identical copy. A type 2 clone is a structural copy with renamed identifiers. A type 3 clone in addition to a type 2 clone has added, removed, or changed parts. Clones often are created by copy&paste. During maintenance of the source code, e.g., if there is a bug fix, or a change due to code optimization that changes the source code of a clone, you will most likely have to apply the change in all instances of the clone. Therefore, if a clone pair is split up because one side of it changed, a developer must check if the change has to be applied to the other side of the clone, too. Type 3 clone findings are hints for already existing potential inconsistencies.

Cyclic Dependency CY

A cyclic dependency is part of a cyclic structure (aka “strongly connected component”) in the call graph (or some other dependency graph structure of your source code). It is possible to navigate through the cycle to come back to your starting point in the code by following a sequence of cyclic dependencies. Understanding and changing code that is within a cycle is harder than in a tree like dependency structure.

Dead Entity DE

An callable entity in the source code that cannot be reached from the entry points of the system under analysis is a dead entity. Even if dead entities do not contribute to the functionality of a system, they do contribute to the maintenance cost: dead entities have to be unit tested, they have to be understood, and they often have to be refactored. When dead code is resurrected, special care has to be taken that there is no ancient bug brought to life.

Metric Violation MV

Code metrics are used to measure properties of code (like its length, its complexity, its nesting) as numeric values. Many metrics have a range of values that are considered ok and values outside this range are normally seen as “not ok”. Code with metric values outside the thresholds violates the metric. In this case, actions have to be taken to improve the code (depending on the idea of the metric), e.g., to ensure it is not too complex or too long.

Style Violation SV

A broad range of findings like MISRA- or AUTOSAR-C++ violations, potential bugs, safety and security anomalies, violations of formatting schemas, violation of coding and naming conventions are labeled as style violations. The actions you have to take to fix a style violation depend heavily on the rule that your code violates. For many rules, there are rationals and hints how to fix the violation given in the respective coding standards.

Multiple Issue Kinds

This icon indicates that there are issues of multiple kinds in the same line.