Introduction
In the following sections I wanna give an overview about the usage of ConQAT as static code analysis tool from an enduser point of view. I wanna explain why I use an additional tool and what information I get from it.
Why an additional tool for static code analysis?
With the Code Inspector (SCI) and the ABAP Test Cockpit (ATC) SAP already provides powerful tools for the static code analysis. I am using these tools (especially SCI) already for years, but there are some usability and functionality gaps which can be closed using ConQAT. Examples for that gaps are:
- Usable visualization of results (with text and graphics).
- Baseline mechanism (define a code baseline for which no remarks are reported, e.g. in case of maintenance projects).
- Historical view on check results (how the code quality increases/decreases over the time).
- Check for redundant coding.
What is ConQAT?
ConQAT (Continuous Quality Assessment Toolkit) is a software quality analysis engine which can be freely configured cause of using the pipes and filters architecture. For a detailed description have a look to ConQAT - Wikipedia. Some key points I wanna take out are:
- Configuration of analysis via Eclipse (using an Eclipse plugin).
- Support of different languages (e.g. Java, C/C++/C#, ABAP). Due to the flexible architecture of the scan engine it can be enhanced for any language. So also for example SQLScript, which comes more and more in the focus for us.
- Integration of results from other tools (e.g. SCI, FindBug).
How is ConQAT used in our ABAP projects?
In our ABAP projects ConQAT is used in the following way:
- It is configured to analyze the coding two times a day. This means that the coding of the to be analyzed packages is extracted and analyzed by the ConQAT engine. This process also starts a configured SCI variant. The results of the SCI run are also extracted and considered by ConQAT. From my point of view I would prefer a higher frequency of analysis runs, but at the moment this is not possible within our landscape. In the future this problem will be solved by the successor of ConQAT (but more on that in the Outlook section).
- The results of ConQAT (with the integrated SCI results) are provided as a HTML Dashboard. On the dashboard an overview section gives a first insight to the results. Within the specific sections different detailed data regarding the analysis can be found. In the dashboard the developer can navigate also down to code level (displayed in the browser) where the remarks are marked at line level. Via an integration of the ADT Links the developer can directly jump out of the dashboard to the coding in Eclipse to edit it.
ConQAT General Information
ConQAT provides the following general information in the result output. In the following chapters I show just the graphical output of a demo analysis, but of course there is also a text output for the objects for which remarks exist.
Overview
The overview page gives an overview about the metrics. It displays how many remarks I have in the whole system and it displays how many remarks I have in the delta to a defined baseline.
Architecture Specification
With ConQAT it is possible to define an architecture specification. It describes which objects can be used by which other objects (e.g. so it can be defined, that the UI layer cannot directly use objects from the data access layer). The relationships can be defined from package level down to single object level. From an ABAP point of view this than be compared to the ABAP package interfaces. The following figure displays a specification which defines the relationships on package level.
Treemap Outline
The Treemap Outline gives displays the analyzed ABAP packages. If the developer hovers with the mouse over a package he gets more information about e.g. the package size (lines of code).
System Size Trend
On the System Size Trend page it can be identifed how the system size grows over time. It is also visible how many lines of code are generated and how many are coded manually (generated objects can be marked in the configuration).
LoC = All Lines of Code (manual, generated, comments)
SLOC = Manual Lines of Code without comment lines
LoCM = Manual Lines of Code with comment lines
LoCG = Generated Lines of Code
Modified Source
The modified source code is also visualized using treemaps. So in an easy way it can be found out where the changes were done in the system (added/changed/removed coding).
Task Tags
ConQAT also can be configured to report task tags (e.g. TODO, FIXME).
ConQAT Code Metrics
Architecture Violations
Violations of the defined architecture (see section above) are displayed in the same graphical way as the architecture specification itself. In addition to the "green" arrows displaying the allowed relations, violations are displayed as "red" arrows.
Clone Coverage
ConQAT analyzes clones within the coding. This is not just a search for exactly the same code parts. The algorithm considers same code structures.
This check helps to detect coding which can be encapsulated in reusable functionalities and it helps also to detect "copy & paste" coding which will lead in most cases to error situations when in later versions not all places are adjusted (because of e.g. a defect, an enhancement). From a Clean Code Development perspective it helps to avoid violations of the "Don't Repeat Yourself" (DRY) principle.
In case the information provided in the dashboard is not enough (even not on code level), ConQAT allows to compare clones with the help of an Eclipse plugin in detail.
Long Programs
ConQAT allows to check for "long programs"; classes, programs, ... which have more lines of code than defined in the configuration. To long classes for example are in most cases an evidence that the Single Responsibility principle is violated.
As in the following figure can be seen, it was configured that e.g. classes up to 600 lines of code are ok (green). Objects with up to 1500 lines of code have to be checked (yellow). More than 1500 lines of code are not ok.
For "lines of code metrics" (like Long Programs and Long Procedures as described in next section) it can be configured if comment lines are considered or not (by default they are excluded). Empty lines are ignored in general.
Long Procedures
The long procedures metric checks methods, functions, ... regarding their lines of code length. Violations for that metric gives us an evidence that to much is done in e.g. one method which has to be extracted in more granular reusable code blocks. The following configuration defines that up to 60 lines of code are ok, up to 150 lines the object has to be checked. All objects with more than 150 lines of code are not ok.
Deep Nesting
Deep nesting is a classical metric which is also checked by ConQAT. Coding is identified which will be to complex to read and to understand because of very deep nestings.
Our configuration allows up to 5 deep nesting levels (which is already a high number). Up to 7 it the coding has to be checked. More than 7 it is not allowed.
integrated SCI results
As mentioned before, ConQAT allows to integrate the results of SCI check runs. It can be defined which check results are marked as critical warnings or as guideline violations. The integration of the SCI results in the ConQAT Dashboard has the advantage, that not several different places have to be checked for remarks and that the results are also provided in a graphical way which gives a better overview. And of course I see directly what has been changed over time.
Further features
In the previous chapters I gave a general overview about the ConQAT features at a high level. The following features were partly already mentioned in these chapters, but I wanna make some further explanations to them to turn out these functionalities.
Baseline Mechanism
ConQAT supports code baselines. That means that you can define a code baseline for which no remarks should be reported in a delta comparsion.
Depending on your project following quality goals are possible:
- No remarks: No remarks in general. That can be applied for new projects, were you start from scratch. But in case a maintenance project is taken over in most cases that quality goal cannot be applied, because the problems are integrated to deep in the system which would lead to additional implementation and tests effort if the problems should be solved (and as we all know, no one wants to pay for such things).
- No new remarks in changed objects: In changed objects no new/additional remarks are introduced.
- No remarks in changed objects: In changed objects no new/additional remarks are introduced and all existing remarks are solved.
Regarding the quality goals "No new remarks in changed objects" and "No remarks in changed objects" the baseline definition helps us to compare what was already there and what is new.
ConQAT analyzes the complete coding, reports the remarks for the whole system, but returns also just the delta compared to the baseline (if configured).
Detailed code analysis in browser
In the HTML Dashboard the developer can navigate down to code level. On a single object level he sees all remarks for the object on the top. When he scrolls through the coding he sees the remarks also by a marker on the left side. So without entering the system, the problems can already be analyzed in detail.
Integration with ABAP in Eclipse
With the ADT Tools so called ADT Links were introduced. Links which can open ABAP objects directly in Eclipse. This ADT Link feature is integrated in the dashboard. So a developer does not need to copy & paste the object name if he wants to edit it. He just has to click on the link to open the object directly in Eclipse ready for editing.
Blacklisting
Not every remark of ConQAT must be a valid remark (cause of different reasons). For that ConQAT supports blacklisting of remarks, so that the remarks are ignored in the furtheranalysis runs.
Conclusion & Outlook
As you have seen, ConQAT is a powerful tool for static code analysis which gives a better overview over the systems code quality. With the integration of the SCI results you have the option to define one single place where all check results can be found and analyzed. Due to the flexible architecture ConQAT allows also that further languages can be analyzed which are in focus in the SAP development context (e.g. SQLScript or JavaScript).
At the moment the only thing I do not really like is that the code analysis only runs twice a day due to our configuration.
Finally I can say, that the code quality has made a big step forward since I am using ConQAT.
- SAP Managed Tags:
10 Comments
