Number of files
In a .NET C# application, C# files containing only custom attributes (as for example AssemblyInfo.cs) are not counted for diagnostic "Number of Files".
Number of lines of code
The number of lines of code displayed in the CAST Engineering Dashboard for a module is calculated in different ways depending on the language type. For object-oriented languages (.NET, Java, C++) the dashboard will use artifact containers (i.e. classes or files) as the basis for calculating a module's total number of code and comment lines, whereas for non-object oriented languages the dashboard will use artifacts (i.e. methods, functions, procedures). Therefore, when specifying criteria for User Defined Modules (UDM) for object-oriented languages, you should specify artifact containers. If a UDM of an object-oriented language contains only artifacts but no container, the CAST Engineering Dashboard displays 0 as value for the number of lines of code and comments.
The reason to base the number of code for object-oriented languages on containers rather than artifacts, is to also include in the count code that does not belong to a specific artifact but is present in the container, e.g. a global variable declaration in C++.
SQL Complexity Distribution
On JPA Named Queries
SQL Complexity Distribution is not calculated for JEE objects of type JPA Named Queries.
In some rare situations, CAST artificial intelligence engine might identify strings that contain the word 'from' and a closing parenthesis ')' or a period '.' as SQL code.
The metric SQL Complexity Distribution lists then the artifact containing the string as 'Low SQL Complexity Artifact' although the artifact does not contain any SQL.
Avoid using SQL queries inside a loop
The diagnostic Avoid using SQL queries inside a loop detects defects in JEE objects only, when the SQL, HQL or JPQL definition is in the loop.
Example: In the following code, the query is defined outside the loop and executed inside the loop:
This code is not reported as a violation, although the execution of the query occurs inside the loop. This is a limitation related to the fact this diagnostic is based on the query definition and not its execution itself.
Avoid Artifacts with High Depth of Nested Subqueries
The diagnostic Avoid Artifacts with High Depth of Nested Subqueries is calculated only for the following languages:
- Pro C
- Pro Cobol
- Embedded SQL Power Builder
Common Diagnostics for ASP Applications
Please note that results for the following metrics and distributions are not correct in the situation described below.
- 6501: Cyclomatic distribution
- 65350 Coupling Distribution
- 65105 Size Distribution
- 7122 Complexity Volume (% of LoC)
- 7124 Functional Evolvability
- 10201 Backfired OMG-compliant Automated Function Points
- 66010 Reuse by Call Distribution
- A (pure) ASP application (i.e. ASP not ASP.NET) having no C# nor aspx source code.
- The application is analyzed with the new (syntax based) .NET Analyzer.
The values for the above mentioned metrics and distributions are arbitrarily high for the application. Correct value range is 0.0 - 1.0. Displayed values are in the range of several hundreds.
Use ASP Analyzer rather than .NET Analyzer for this type of application.
In all .NET rules, C# objects and VB.NET objects are not distinguished and considered as belonging to the same technology. As an example, the total number of VB.NET methods includes also the number of C# objects.
C++: Avoid Classes with at least one virtual Method and without a virtual Destructor
This diagnostic lists incorrectly a class as Very High Risk Object, when the class has not its own virtual destructor but inherits a virtual destructor from an external class. This is because external classes are not saved in the Knowledge Base. This limitation does not apply, when the external class has been previously analyzed as a non-external class in a separate job and therefore has been saved in the Knowledge Base together with its virtual destructor.
The PB diagnostic-based metric Avoid undocumented methods returns PowerBuilder proxy objects as "undocumented". However, these objects are not created by the user and there is no means to document them. As a result you may find that you have a higher number of objects returned by this metric than expected. To work around this issue, make sure you exclude PowerBuilder proxy objects from any documentation metric.