How To Get Accurate Feedback From The SonarQube Ecosystem Into C++ Directly

Late feedback is a pain in the butt. Regardless of how it comes, hearing "that thing you did two weeks ago was wrong" is unwelcome at best. Good feedback is immediate, actionable and at least dispassionate, if not compassionate.

That's why we help you integrate C++ static analysis throughout your workflow, so you and your team get the feedback you need when and where it's most useful.

In this post, I'll walk through how SonarQube and SonarLint integrate smoothly into your workflow and your team to give you the right data at the right time and in the right place. 

Most experienced developers understand that coding is a bit of a team sport. Success requires both individual performances as well as cooperation and, well, teamwork. That's where SonarQube comes in. It helps teams coalesce around shared standards and a shared vision of quality. The two biggest pieces of this are the Quality Profile and the Quality Gate. 

Your code; your standards

A Quality Profile is a subset of rules applied during analysis to raise issues on your code. The out-of-the-box profile is named "Sonar way", and we work hard to make sure the Sonar way profile for each language is uncontroversial.

Currently Sonar way for C++ consists of nearly 300 rules, 44 of which tie back to the C++ Core Guidelines championed by Bjarne Stroustrup and Herb Sutter. The idea with the default profile is that your first analysis should only raise "no brainer" issues; ones that most people will obviously want to fix (E.G. null pointer dereferences). 

But narrowing the profile to only uncontroversial rules, means that we've omitted the rules for special situations. For instance, beyond the 44 C++ Core Guidelines rules in the default profile, we've implemented another 18 rules that aren't in the default profile.

Why?

There are a few different reasons. First, some only make sense when you're writing very modern C++, but would be very noisy on code written in an older style. Another sub-set is more stylistic than anything else, and there's no consensus about those rules even if they are in the core guidelines.

But anyway, those rules - and a lot more - are available, and you can easily add them to your own custom profiles to make sure you apply the best rules for your team and your code base.

The other big piece of coalescing the team around shared standards is the Quality Gate, which is the list of boolean conditions  (E.G. test coverage on new code > 80%) your project must meet to be considered releasable.

Again, we provide what we believe to be a sane default. But the idea is that you'll set your Quality Gate up to reflect what your team sees as the minimum standards to release to production.

At every analysis, the project is tested against those conditions to yield a pass/fail releasability status so you always know whether your code meets your own minimum quality standards for release. And with webhooks, we make it easy to reflect your Quality Gate status back to your pipeline, allowing you to fail the build if you need to.

Earlier is better: PR analysis

But of course, the earlier feedback comes, the better. Personally, I'd rather know there's a problem before I break the whole team's build. That's why we've implemented pull request analysis and decoration both on-prem and in-cloud for GitHub, GitLab and Azure DevOps, as well as for Bitbucket Server.

The setup for this can be inherited from the main build, with the addition of a few extra PR-specific parameters. But if you're using Jenkins, Cirrus CI or GitLab CI, even that's taken care of for you. In those CIs we read the PR values from the environment so there's nothing extra to do.

Then, with the addition of a little one-time configuration in your SonarQube project, you can have your PR annotated in GitHub/GitLab/etc with the analysis results and Quality Gate status.

The obvious advantage is that your static analysis results are delivered to you in the interface you're already using; you don't have to go looking for them. 

That's great from both sides of the peer-review equation. As a PR submitter, you get early notice of the simple stuff so you can get it cleaned up before you ever ask for review. And as a reviewer, you can come to a PR knowing the team standards have already been met.

No more arguments about whether `const` should be used. That's baked into the team's Quality Profile and already taken care of by the time you see the code. All you have to do is focus on the logic of the PR: does it fulfill the requirement in an optimal fashion?

Earliest is best: in-IDE analysis

But of course, the earlier feedback comes, the better. Personally, I'd rather know there's a problem before I commit. That's why we've created SonarLint, which is a free plugin for Visual Studio. With each save, the file you're working on is re-analyzed so any new issues are raised to you immediately and you can fix them before commit.

If you have any questions about why there's a problem with your code, the rule description is close at hand. It'll help you understand what could go wrong, and give you code samples demonstrating a fix.

By connecting SonarLint to your project in SonarQube, you can make the experience even better. Out of the box, SonarLint applies the Sonar way Quality Profile. Once you're in connected mode, the Quality Profile chosen by your team is applied instead.

Not only that, but connected mode also syncs issues that you and your teammates have marked Won't Fix or False Positive on the server, so that you're never bothered with them in SonarLint.

Quality; full circle

And that brings us full circle. SonarQube allows the team to coalesce around a shared vision of quality (these rules, those release criteria). With pull request analysis, you can apply that vision to your code not just before merge, but even before peer review. SonarLint brings static analysis into your IDE, and SonarLint's connected mode pulls in the team's standards from SonarQube. 

Developer surveys show that most C++ developers are seasoned, with at least 5 years' experience and more likely 10 years or more. That means you've both mastered your craft and come to realize how much you still don't know.

You've seen the language grow and evolve, and understand that more change is always in store. You're past wanting to reinvent the wheel, and happy to exploit the tools at hand with minimum effort for maximum benefit.

And that's where SonarQube and SonarLint static analysis come in. They'll help you stay on top of not just absentminded goofs and evolving language standards, but also the tricky bugs that only show up under the right conditions.

(Also published here)

(Disclaimer: The author works at SonarSource)