PVS-Studio user support often receives clients' suggestions on product improvement. We are happy to implement many of them. Recently one of the users suggested refining the automatic notification utility for developers (Blame Notifier). They asked us to make Blame Notifier extract the date/the code revision to which the analyzer issued a message using blame information from the version control system. This feature allowed us to expand the utility capabilities, which we'll discuss in this article.

How it all started

One of our clients said that he needed to sort through newly received analyzer warnings and previously found ones. The discussion showed that the user wanted to focus on warnings for new or just-changed code. We hurried to say that it was possible using SonarQube in conjunction with our plugin. The client responded quickly and noticed that it was certainly pointless to use a third-party tool. For example, SonarQube. Because it's quite an extended tool for these purposes.

Since the user has a large code base, we offered to logically divide the use of the static analyzer into before and after the adoption of static analysis, temporarily suppressing previously found warnings with our suppression mechanism. After that, the analyzer would issue warnings only for new or changed code. In addition, we outlined the Blame Notifier implementation, so that all people involved in the development would immediately get notifications about new warnings. The client liked such an idea but wanted to see both old and new warnings in the report. So, the user found such an operation mode a bit inconvenient. Besides, we received the following feedback on Blame Notifier: "It would be cool if warning notifications were more informative, for example, they could contain the date and the revision number".

And then it hit us. Previously, we thought that we had to create our own database to make a more intelligent and informative notification system. Based on this system, we could track a life cycle of each warning and, accordingly, determine which of them are new. But the client's email helped us realize that the version control system is the very database from which we can get all the necessary up-to-date information. After all, by binding to commit revision numbers, we can calculate their binding to the modification time of corresponding code lines. Moreover, we already get this information through blame. So, we just have to use it.

We suggested the following option:

the user receives the resulting analyzer report with all the warnings;
the user can configure Blame Notifier to have an HTML report of warnings only for the newly changed code. Besides, warnings contain the date and the revision number.

That's what we agreed on!

About the utility

Blame Notifier automatically notifies developers with warnings found by PVS-Studio, for example, after night builds. The utility generates an HTML report for the developer with only their warnings while a super-user receives a full warnings report. A full report by default contains grouped warnings sorted alphabetically by developers. Such a feature is extremely useful because the utility immediately notifies interested parties of new warnings. As the utility name suggests, it is based on blame information obtained for files checked by the analyzer. These files come from the user's version control system.

If you are not familiar with this utility, you can learn more in this article.

What's new?

Previously, we could extract the developer's name from the blame information. Now, we also can extract the date and the revision number of the last code change that triggered PVS-Studio. The additional extracted information allowed us to add new options to the utility:

--sortByDate (-S) – allows you to generate an HTML report containing warnings sorted by the date of the source code change, due to which the analyzer issued a warning. Warnings for a certain date are grouped according to developers.
--days (-d) – an HTML report gets warnings for code whose modification date is less than some number of days from the date of the current utility run.

Note. Only SVN, Git, and Mercurial support the date/revision number extraction.

By default, an HTML report looks as follows:

This is a new report sorted by date:

How can you apply it?

The new options allow simulating the SonarQube behavior when loading the analyzer report with 'sonar-scanner'. Let's dwell on that.

Note. If you use PVS-Studio with SonarQube, the implementation described below is irrelevant for you. Because you already have the corresponding processing of new warnings built into SonarQube. If you use PVS-Studio separately, and you don't have the opportunity or desire to deal with SonarQube, then it may be interesting for you.

To begin with, SonarQube uses 'Clean as You Code' approach of code quality control. The point is that developers should pay special attention to the reliability and security of new code that has just been added or changed. That is, old well-established code should take a back seat. Instead, you have to focus on current development to prevent new problems. So, you may return to long-existing problems from time to time and fix them. You can learn more about this approach in the SonarQube blog.

They implemented this approach as follows. There's a section with new issues for a chosen time period on the project's main page. "Quality Gate" is configured to find new issues. It is the so-called indicator that checks whether the new code compiles with the specified threshold metrics. For example, it shows:

the number of new bugs;
the number of new vulnerability issues;
the technical debt ratio;
coverage on new code;
... and so on.

Let's say, every morning you download a new analyzer report. If the threshold value of any metric is exceeded, 'Quality Gate' will notify you.

'Clean as You Code' approach is user-friendly. Here is an example of what it looks like in SonarQube 7.9.4:

SonarQube is a professional tool. It allows you to monitor the quality of a software product conveniently and effectively. For example, SonarQube:

separates code's existing issues from newly found ones;
provides various metrics and graphs;
allows you to filter issues by criteria;
makes it possible to view warnings found by code quality control tools in the code checked directly from a web browser;
... and much more.

If you use SonarQube, check the article to learn how to integrate the results of the PVS-Studio analyzer with it.

But what if you don't use SonarQube?

If you have the opportunity, you can install it, but you must perform the deployment in advance, install the program, and complete the initial setup of SonarQube. It may cause some difficulties with:

running the SonarQube server;
setting up 'Quality Profiles';
setting up 'Quality Gates';
using 'sonar-scanner';
... and so on.

However, not every development team needs all the features provided by SonarQube. So, it's possible that such a long and quite challenging process of deploying and maintaining may well be redundant.

And this is where our Blame Notifier utility comes to the rescue. It has already been able to replace some of SonarQube's capabilities in notifying developers. New utility features imitate an easier version of the 'Clean as You Code' approach, where the main code quality metric is the introduction of new analyzer warnings. In this mode, the mailing list contains warnings for code whose modification date is less than a certain number of days starting from the current utility run.

Let's go over SonarQube's behavior. To do this, we specify 10 days for the '-d' option and sort the warnings (-S) by the date of the code change that caused the warning. In this case, the HTML report looks as follows:

Evidently, the report contains 11 new warnings for the last 10 days. It looks almost the same as in SonarQube. However, it's much simpler to get such reports.

Such an "easy" approach, of course, has its drawbacks:

new code quality is only measured by one metric;
an HTML report does not include warnings about code whose modification date is outside the chosen time period. To that end, you need to get a full report for the entire time. At first, you must run 'blame-notifier' without limiting options.
and, of course, there is no possibility to navigate through the code checked directly using a web browser

It is also worth mentioning that the use of the Blame Notifier utility and the PVS-Studio plugin for SonarQube is only available with the PVS-Studio Enterprise license.

Conclusion

The development process of static analysis technology involves not only running the analyzer and getting a report. Usually, a static analyzer and subsidiary utilities/plugins go hand in hand. The latter makes it easy and convenient to maintain the code quality.

For example, PVS-Studio has many plugins (for Visual Studio, SonarQube, Jenkins, Gradle/Maven/IntelliJ IDEA). It also has PlogConverter, a utility for more convenient reports conversion and blame-notifier, a utility for notifying developers. PVS-Studio team's experience and user feedback help to constantly improve the product. To keep pace with tool changes, do not forget to check the blog on our website.

The new Blame Notifier's operation mode eases the work of some functionality. Previously, it was available only with SonarQube. However, I'd like to mention again that in no way we encourage you to stop using SonarQube. The new mode only simplifies this approach and suggests using static analysis. We believe that many teams will appreciate this mode.

If you have any suggestions for improving our product, do not hesitate and write to us right away.

PVS-Studio New Features for Notifying Developers About Errors Found