Static Analysis

Static Analysis is a technique for checking software for various issues, such as bad code, vulnerabilities, potential bugs, compliance to certain standards, etc. without executing the software. IDz is providing customers with static analysis capabilities for a long time, supporting languages like Java, COBOL and PL/I.

Figure 1. Starting Static Analysis.

To analyze your source code, you can right click on any project, select Software Analyzer -> Software Analyzer Configurations and double click Software Analyzer to create a new configuration. Then you can choose whether you want to check the entire workspace, or some projects or working sets and switch to the Rules tab where you can select the rules you want the source code to be compliant with.

Figure 2. Creating Analysis Configuration.

Rules in IDz are grouped according to following hierarchy: the top element is rule provider; rules from two distinct providers are so different that they are using generally incompatible data models and require results to be displayed in separate views. The next level of the hierarchy is rule category, which is just a logical grouping for sets of rules that have something in common, e.g. globalization, security, naming conventions, etc.; finally, there are rules themselves.

Figure 3. Selecting Rules.

IDz is shipping providers of two kinds: Code Review and Metrics. Code Review providers contain rules with violations occurring at specific location: e.g. java naming convention dictates to use camel case starting with a lower-case letter for variable names. If you use a different convention for some variable, then the place in code where you declared it is marked as rule violation.
Metrics rules give more general picture of code quality, i.e. a class containing too many lines of code and too little comments is considered a violation. Typically, the precise definition of “too many” and “too little” can be adjusted by selecting appropriate thresholds in the properties pane beneath the rule selection.

Figure 4. Adjusting Parameters for Metrics Rules.

Once you have picked all rules for analysis you can click Analyze button and wait for the results to appear in Software Analyzer Results view. Having those results, you could then fix the found issues, export them in xml format or make a report.

Figure 5. Analysis Results.

Static Analysis Results Persistence

So far so good, but before IDz 14.1.5, if you close the workbench and open it again you will notice that analysis results are completely gone. There was no way to track how the source code quality is changing over time unless exporting results into xml and writing some custom tool to display data. It is also impossible to import those xml files back and see them as analysis history view entries, they just don’t have enough data for this purpose.

In IDz 14.1.5 you may close and open the workbench as many times as you want, analysis histories remain there, and results are fully functional: all actions that can be done to results originating from current session, i.e. quick fixes, exports, reports, can also be done to results from past sessions and the outcome is the same.

Static Analysis from Command Line

Static analysis can also be run in batch mode or from a command line. This can be useful in settings like running analysis as part of nightly builds or checking the code that developers are delivering into a source control repository.

First thing that needs to be done is exporting rules to a file: from the Rules tab of Software Analysis Configurations dialog select rules you want to use in command line analysis later and click Export button.

Now, let us assume you have created a directory C:\temp\export to get analysis results there and exported rules into the same directory; the source files you want to analyze are in a workspace C:\my_workspace, project my_project’s src folder. Then the command looks like the following

eclipse -application -data C:\my_workspace -rulefile C:\temp\export\rules.dat -exportDirectory C:\temp\export -directory C:\my_workspace\my_project\src

This command will create a lot of xml files containing analysis results. Another option could be using -reportDirectory switch instead of -exportDirectory, in which case it would create some html reports.

However, before IDz 14.1.5, there was no way to work with these results in the workbench, i.e. it was impossible to import any of the exported xml files. Developers had to manually inspect reports and fix issues one by one or write their own xml parsers and integrate them into the workbench.

In IDz 14.1.5 command line export results can be imported into the workbench. In the export directory the command creates a file with extension .xml.sazip. This is just a plain zip archive containing sources and an xml file with analysis results. To import this archive just open the Software Analysis Results view and click the Import button.

Figure 6. Importing Analysis Results.

In general, the workspace you are importing results to, does not have to contain the same source files, but if it does, which should be the most common use case, during import it is trying to match files from sazip with files in workspace. If no matches are found for a file, it is imported into a temporary folder StaticAnalysisProject.

Figure 7. External Sources Imported into Temporary Folder.

Similarly, to persisted analysis histories, these imported results are fully functional: you can open files, fix issues, apply quick fixes, etc.

Join The Discussion

Your email address will not be published. Required fields are marked *