How to step over legacy and start using static code analysis

The legacy code problems are familiar to the vast majority of software developers. The process of turning the code into legacy is inevitable, because progress in programming does not stand still. Projects either "die" forever, or require constant support and writing new functions. Thus, in any project in any programming language, the legacy code arises and delivers various inconveniences during further development. Using the example of PVS-Studio, in this article I will explain how to immediately start using a static code analyzer in my project.

Introduction

First, let's look at the definition of a legacy code and get acquainted with the PVS-Studio static analyzer.

The term legacy is not always associated with the age of the code. Here are some of the most common definitions:

1. The code is not covered by tests - usually a very serious reason to make changes to such a code as little as possible;
2. Outdated code - long forgotten how it works. And if it is also not covered with tests, then the situation is absolutely sad, because the code is still in use and needs support.
3. Third-party code is similar to the previous definition, but even in the new, alien code, the described problems may arise;
4. The code is kept for compatibility - such code is usually old and is not likely to be tested with what it should be compatible with;
5. Other similar definitions.

In any of the situations described, the developers try to change the code as accurately as possible when developing the project so as not to break anything. Additionally, the project can use techniques and tools for writing more efficient and high-quality code. In this case, the old code may need to make even more changes. A few examples include the use of a modern language standard, the compliance of a style guide and the introduction of a static code analyzer. Unfortunately, any of these ideas is faced with an obstacle in the form of a legacy code. It can be everywhere: it cannot be separated as test files or third-party libraries. Virtually all tools that offer code modification have the ability to mark up the code to turn off warnings, but in practice this method cannot be applied. When you first use this tool, no one will allow you to mark out hundreds of source code files with thousands of comments - this is a very large amount of modified code, due to which viewing changes in SCM (Source Control Management) systems will become very difficult. Therefore, a system for mass suppression of warnings was developed for the static analyzer PVS-Studio without the need to modify the source files of the project. This feature allows you to easily integrate the analyzer into any project and IMMEDIATELY start to benefit from it, i.e. find new bugs.
')
PVS-Studio is a static analyzer for detecting errors in the source code of programs written in C, C ++ and C #. Able to run on Windows and Linux, integrate into build systems, various IDE and continuous integration systems.

Principle of operation

The suppression mechanism is based on the use of special files of the “bases” of the analyzer messages that are added next to the project. These files contain messages marked up for this project as "unnecessary." At subsequent checks of files of this project by the analyzer, it will automatically check for the presence of such files next to the project and, if they are detected, will not show messages that are contained in such a “base”. Note that modifying the source file containing the marked messages, and, in particular, the line shift, will not lead to the re-appearance of these messages. However, editing a line containing this message may cause it to reappear, because such a message is already becoming "new."

Using the suppression mechanism in Visual Studio (Windows)

The PVS-Studio plugin, conveniently integrated into the IDE, is available for Microsoft Visual Studio. It allows you to run an analysis of the entire solution, specific projects or files, and also supports incremental analysis .

The “Suppress Messages ...” item is available in the PVS-Studio menu (Figure 1), which opens a window for working with suppressed analyzer warnings (Figure 2).

Figure 1 - PVS-Studio menu in Visual Studio

Figure 2 - Window for suppressing analyzer warnings

In the window that opens, several actions are available:

1. Suppress Current Messages - suppress all analyzer warnings;
2. Clear Selected Files - restore hidden warnings for all or some projects;
3. Display Suppressed Messages - display hidden analyzer warnings in the window (PVS-Studio Output Window) with the rest of the warnings. In this mode, you can return to correcting previously suppressed warnings. Such messages will be marked in a special way (crossed out), so they can not be confused with others.

To view the results of the analysis in Visual Studio there is a special window (Figure 3).

Figure 3 - PVS-Studio Output Window

A special window allows you to navigate through the found warnings and go to the code to fix it. The PVS-Studio window provides wide possibilities for filtering and sorting results. Also there is the possibility of a quick transition to the documentation of the selected diagnostics.

Additional options for working with each message are available in the context menu by right-clicking on the message (Figure 4). A command is available here to suppress the highlighted alert. When you open the menu on an already suppressed alert, the item will be available to return the trigger.

Figure 4 - Analyzer warning context menu

Using the suppressor mechanism in Standalone (Windows)

PVS-Studio can be used independently of the Visual Studio integrated development environment. The Standalone tool provides features for checking the code, regardless of the compiler or build system used, and then allows you to work with the analysis results, providing a user interface similar to the Visual Studio PVS-Studio plugin (Figure 5).

Figure 5 - PVS-Studio Standalone

Standalone also allows you to work with the analyzer report obtained by directly integrating it into the build system, if the user does not have Visual Studio.

The Standalone menu for launching analysis and warning suppression is as follows (Figure 6).

Figure 6 - Standalone Utility Tools Menu

When you select the menu item to start the analysis, the “Compiler Monitoring (C / C ++)” window will appear (Figure 7).

Figure 7 - Build monitoring start dialog

To filter analyzer warnings, you must specify a file with previously suppressed warnings before analyzing. You can create and replenish such a file through the “Message Suppression ...” menu, which is the same as was presented in the section about Visual Studio in Figure 2. After the analysis is completed, only new errors will be displayed in the PVS-Studio window. Without a file, the analyzer will give all the results.

Using the suppression mechanism in Linux

In Linux, the commands of suppressing and filtering messages of the analyzer are executed only in the console, but when they are automated on the server, the mechanism of suppressing messages becomes very convenient.

There are several ways to use this mechanism, depending on the integration option of the analyzer.

Analysis using the pvs-studio-analyzer utility

To suppress all warnings of the analyzer (for the first time and in subsequent cases), the following command must be executed:

pvs-studio-analyzer suppress /path/to/report.log 

Project analysis can be run as before. At the same time suppressed warnings will be filtered:

 pvs-studio-analyzer analyze ... -o /path/to/report.log plog-converter ... 

With this launch, suppressed warnings will be saved in the current directory in a file called suppress_base.json , which must be stored with the project. New suppressed alerts will be added to this file. If you need to specify a different name or location of the file, you can add the commands above by specifying the path to the file with suppressed warnings.

Direct integration of the analyzer into the assembly system

Direct integration of the analyzer may look as follows:

 .cpp.o: $(CXX) $(CFLAGS) $(DFLAGS) $(INCLUDES) $< -o $@ pvs-studio --cfg $(CFG_PATH) --source-file $< --language C++ --cl-params $(CFLAGS) $(DFLAGS) $(INCLUDES) $< 

In this mode, the analyzer cannot simultaneously check source files and filter them. Therefore, additional commands are required to filter and suppress warnings.

To suppress all analyzer warnings, you also need to run the command:

 pvs-studio-analyzer suppress /path/to/report.log 

To filter the new log, use the following commands:

 pvs-studio-analyzer filter-suppressed /path/to/report.log plog-converter ... 

The file with suppressed warnings also has the default name suppress_base.json , for which, if necessary, you can specify an arbitrary name.

Using the suppression mechanism in the SonarQube

SonarQube (formerly Sonar) is an open source platform for continuous analysis (continuous testing) and measuring code quality. A plugin for PVS-Studio is available to users of this system. SonarQube reduces the results of the analysis to a single information panel, leading the history of the runs and thus allowing you to see the general trend in software quality changes during development. An additional advantage is the ability to combine the results of different analyzers.

So, having received the results of the analysis of one or several analyzers, you need to go to the list of warnings and click on the “Bulk Change” button, after which the next menu will open (Figure 8).

Figure 8 - Mass change in error status

In this window, you can mark all analyzer warnings as “won't fix” and in the future work only with new errors.

What to do after suppressing all warnings?

Configure static analysis on the assembly server and developers' computers. In the future, correct new warnings of the analyzer and prevent them from accumulating. It is also worth planning a search and correction of errors among suppressed warnings.

Additional control over the quality of the code will help ensure the distribution of results by mail. It is possible to send warnings only to those developers who have made an erroneous code, possibly using the BlameNotifier utility, which is included in the PVS-Studio distribution kit.

It may be convenient for some to upload the results to Jenkins or TeamCity using the PVS-Studio plugin, and send a link to this page.

Conclusion

Passing the analyzer warnings on the legacy code is not the only scenario for using the presented mechanisms. Mass suppression of warnings makes it easy to integrate the analyzer into any project and immediately begin to benefit from it, i.e. find new bugs. This implementation allows you to schedule fixes for missed warnings in the future without distracting developers from current tasks. Also, this mechanism can be used further to suppress false positives and warnings, which for one reason or another will not be corrected.

The article lists all possible ways to suppress analyzer warnings at the moment. The collected material is based on the documentation for the PVS-Studio analyzer, but the details on this topic were discussed in more detail than in the documentation. General information may not be very informative for new users, so you should read the documentation on the links below.

1. General information about the principles of working with the PVS-Studio analyzer ;
2. PVS-Studio Standalone ;
3. How to run PVS-Studio in Linux ;
4. Embedding PVS-Studio in the process of continuous integration ;
5. Integration of PVS-Studio analysis results into SonarQube ;
6. Work with analysis results (.plog file) .

An alternative way to reduce the number of analyzer alerts to zero is to fix all analyzer alerts at the initial stage. In this way, Epic Games took advantage of the Unreal Engine project. You can read more about this in the article: " How the PVS-Studio team improved the Unreal Engine code ."



If you want to share this article with an English-speaking audience, then please use the link to the translation: Svyatoslav Razmyslov. How To Step Over Static Code Analysis