Static Code Analysis HOWTO

Last week I promised to write about different static source code analysis tools and methods we’re using. Here you go:

Finding bugs

The rationale for using this kind of analysis is obvious. Of course we want to catch bugs as early as possible.

For C++ code, we’re using CppCheck together with Cppcheck Plugin for Jenkins for finding bugs that a C/C++ compiler doesn’t see. CppCheck Jenkins plugin has nice configuration options:

We’ve set our jobs so that if there are any new errors, the build will be marked as failure. We also have unchecked ‘Style’ issues from the severity evaluation as we’re mostly concerned about real errors. With this configuration we haven’t had any false positives reported this far.

Needless to say, all problems reported by CppCheck need to be fixed immediately. Developers are also able to run CppCheck analysis on their own development environments.

When the build fails, all who committed code in that build will receive an e-mail stating that it might have been their commit which broke the build. The mail is also Cc:d to all other developers working in the project.

Finding duplicate code

Duplicate code is bad. Not only can it be considered as waste, but it also means that when code is changed, all the duplicates of it probably need to be changed as well. And as one might not even know that some piece of code is duplicated, it’s likely that e.g. a bug fix is only done on one occurrence of the same code. Therefore we want to minimize the amount of duplicate code.

For finding out duplicate code we use a tool called PMD’s Copy/Paste Detector (CPD) together with Jenkins DRY Plugin. Also here we have taken similar approach as with other analysis, if the amount of duplicate code grows, we will mark the build as unstable or failed. CPD works with Java, JSP, C, C++, Fortran and PHP code.

Finding Complex Code

For C/C++ code, we use a tool called CCM to find out code which is potentially hard to change. CCM measures the Cyclomatic Complexity of code. Even though Jenkins supports running CCM as part of the build, it is missing the features for setting thresholds based on CCM results. Therefore we writed a small Python script to parse the CCM’s XML report and calculate the amount of High risk methods (cyclomatic complexity 20 or more) and the amount of Medium risk methods (cyclomatic complexity 10 or more). The script takes in threshold values for high and medium risk methods and fails the build in case high risk threshold is exceeded. In case medium risk threshold is exceeded, the script outputs a warning text and we use Jenkins Text Finder plugin to mark the build unstable.

For Java code, we get the complexity figures from Clover report. With that we also need to use a custom Python script for parsing the results.

Advertisements

One response to “Static Code Analysis HOWTO

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s