Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
X
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Reading Time: 8 minutesThe popular picture we frequently see among our customers is a Git-based development environment with a dynamic approach to branching and merging. Teams expect static analysis to seamlessly integrate into these kinds of workflows.
With large and complex codebases, teams expect modern static analysis tools to:
With the 2020.2 release, we have introduced a collection of enhancements for Parasoft C/C++test that make it an even better fit for modern workflows. In this post, I’ll highlight some of the most interesting novelties:
Static analysis sessions, especially on large codebases, can be lengthy. This is problematic for developers working on small increments for functionality or bug fixing. They like to get quick feedback on the most recent files they modify and correct the code when everything is still fresh in their memory. They prefer the speed of analysis over accuracy in this phase.
In Parasoft C/C++test 2020.2, we enhanced our Git integration. It can now automatically adapt the scope of the analysis to focus only on the recent code modifications.
Developers can specify a parent/reference branch to compare against their current development branch. Parasoft C/C++test will automatically compare and compute the delta for analysis.
Instead of running the analysis on the entire project, which may take significant time, even hours, we run it on the minimal set of files that are automatically selected by the tool. It can dramatically reduce the duration of the analysis session.
Naturally, some of the checkers, that require a system-level view of the project, will not be 100% accurate. We recommend combining fast, restricted runs with extensive and complete CI/CD scans.
To enable this feature, users need to specify two options. See the screenshot below for an example of a “localsettings” file for use in the C/C++test Standard edition, using -localsettings command line flag for cpptestcli.
scope.scontrol.files.filtr.mode decides if the scope for analysis shall be computed based on the branches comparison or locally modified files. To compare two branches and focus the analysis on modified files only, users need to provide a reference branch, using the scope.scontrol.ref.branch option.
For C/C++test Professional, you can use the same localsettings file to configure this functionality. The localsettings file needs to be added to the C/C++test professional configuration using Parasoft Menu > Preferences > Parasoft > C/C++test advanced settings > Settings file.
This new functionality improves developers’ productivity by shortening the duration of analysis sessions and focusing analysis on modified files only. But developers may want to make their static analysis even more focused. Read on to learn more!
Teams frequently must work with codebases developed without compliance in mind. It may be uncompliant legacy code or a prototype developed without compliance. Trying to enforce a coding standard in this kind of situation can be a real nightmare.
Teams know that clean code is a must at some point. But this is not their primary goal. First, they want to make sure they don’t introduce any new problems and don’t increase compliance debt.
The problem is that it’s very time consuming to distinguish between new and pre-existing violations. Even with the Git integration and reduced scope of the analysis, as soon as the developer modifies the file to add new code, all pre-existing violations will show in the report. Reviewing those problems can take hours.
Teams can remedy this problematic situation by baselining the static analysis results. The 2020.2 release of C/C++test provides an option to specify the reference report with the project’s accepted state when running the analysis session.
The reference report compares the complete results of the analysis session. It filters out pre-existing findings and reports only the new problems.
For developers, it means that instead of reviewing hundreds of violations they can focus on these three that appeared after their code modifications.
To enable results baselining users need to first generate the reference report.
For C/C++test Standard follow the steps below to generate the reference report.
For C/C++test professional, use a dedicated option to generate the reference report.
2. Store the reference report in the SCM if you want or use it from the local drive.
3. To see the new results only, run the analysis on your current branch with two additional options in the advanced settings file: Parasoft Menu > Preferences > Parasoft > C/C++test advanced settings > Settings file.
All examples of the local settings file with report.xml specified, you can also include relative or absolute paths.
When discussing the Git integration and reduced scope of analysis for faster feedback, I previously mentioned that these reduced scans should be complemented with the complete and extensive scans in the CI/CD.
With this approach, an important question arises: How does a user enable CI/CD results for developers so they can take action and remediate? There are several ways to make the results available:
Most teams prefer the last option because they can access results through the interface they use most — their IDE!
Our latest release also enhances the Visual Studio Code extension by enabling the download of static analysis results from DTP. This functionality has been available in our plugins for Eclipse and Visual Studio.
The results download operation is straightforward. Users invoke a dedicated command from the Command Palette: “C/C++test: Load Results from DTP …”.
The extension will ask the location of the DTP server followed by credentials, and then the DTP project and filter.
Voila! Results are available in the Problems view as they were generated locally.
Developers can also click on the violation message. It takes them directly to the source line where a fix is required. It’s incredibly productive.
Teams serious about integrating static analysis understand that managing suppressions or waivers effectively is critical to its success. Parasoft users can store suppression information directly in the source code in the form of code comments or use an external database such as Parasoft DTP or TCM.
Storing suppressions information in the form of code comments is probably the most effective way of managing these exceptions. But many teams are not allowed to do so, especially when delivering code to an external contractor who may be using different tools. Or maybe there’s an internal policy that forbids doing so.
We have introduced a new third way of suppressing violations that don’t require making any code file edits. This eliminates polluting the source files with any suppression information.
This new suppression method allows for suppressions to be stored in a plain text file. There’s one suppression file per source code folder. Suppression files have a standardized name: parasoft.suppress. Starting with the 2020.2 release, all Parasoft static analysis tools are preconfigured to include parasoft.suppress files in the analysis. There’s no additional configuration required to enable this functionality.
Users can add new suppression entries to parasoft.suppress either by using dedicated UI action or by adding these entries manually. The UIs of the Eclipse plugin, Visual Studio plugin, and Visual Studio extension are extended to support the new suppression type.
Suppression entry is just plain text and contains a collection of attributes that identify the violations to suppress. See the screenshot as an example of a suppression entry and a list of all attributes that are supported in suppression entries.
Developers can use basic regular expressions (‘*’, ‘?’) for the message attribute, which enables suppressing multiple violations with one suppression entry. For example, when a message contains a parameter name.
If needed, a single suppression entry can suppress multiple violations. However, the information about each individual suppressed violation will also be available in the generated reports. And, if configured for it, propagated into the DTP server.
Suppression files (parasoft.suppress) are designed to be stored in the SCM. When a branch is created, suppression information is a part of it. Adding a new entry to the suppression file makes it visible in the code review process and the file goes through the approval chain. After merging the code, suppression files become part of this operation just like the source code. Plain and simple.
Modern development workflows standardize based on Git SCM and focus on the CI/CD. Large codebases and a high frequency of branching require deploying static analysis tools that can automatically focus and produce outcomes relevant to the developer’s current work.
Due to open source, legacy, and prototype source code that projects frequently need to work with, teams have to determine their own pace and build their own plans to achieve coding standards compliance. Results baselining helps establish a strict policy for the new code and a plan for addressing pre-existing problems quickly and efficiently.
Product Manager for Parasoft's embedded testing solutions, Miroslaw's specialties include C/C++, RTOSes, static code analysis, unit testing, managing software quality for safety-critical applications, and software compliance to safety standards.