30% of C++ developers are not using static analysis at all1. Of those using static analysis, maybe half are not using static analysis tools for teams. Why is that so?
It is received wisdom that C++ static analysis is a pain to get properly working. But again, why?
Generally, it is because C++ tooling is very fragmented and building C++ projects is far from streamlined. Static analysis is commonly configured with information from that build. But there is no way to get it automatically; hence the pain.
So it seems impossible to offer serious C++ static analysis with a great configuration experience. Users must suffer the pain, or not use it at all.
Well, at Sonar we believe in making the impossible, possible and so we've gone ahead and solved this once and for all!
SonarCloud’s automatic analysis for C++ simplifies the process of code analysis by enabling you to analyze your code with just one click, eliminating the need for any manual effort on your part. Better still, it is free on SonarCloud for public projects. You can use it on your own public project or just fork any open-source project on GitHub and get it analyzed.
Before we talk more about this achievement let's dig into why it's so important to be able to analyze C++ code, and why, until now, it has been so hard.
C++ has fervent supporters and detractors. The iconic pros and cons have been discussed in great length.
Here, I would like to look at it from the angle of static analysis users.
- C++ is a very flexible multi-paradigm programming language. It enables high-complexity software development with very refined patterns. At the same time, it can be very complex, making it elitist and very easy to misuse. Static analysis tools can mitigate this downside without detracting from C++’s power.
- Simultaneously, C++ allows (very) low-level programming, including direct access to the hardware and using an assembler. It addresses a vast range of application domains, including those related to embedded applications. As a drawback, manual resource management is very error-prone and can lead to critical consequences. After all, memory management and access is the first known source of vulnerabilities2. Here again, static analysis can help by pointing out pieces of code that go against good practices and catching some very nasty bugs such as memory-related issues.
Obviously, at Sonar, we believe in the genuine value that static analysis can bring. And we are sad that 30% of developers state they are not using any Static Analysis tools3. We think that all developers should use such tools.
The remaining 70% use a wide variety of tools but mostly those built into their IDEs. Of course, they all have different capabilities, and although I believe Sonar offer the best ones for most situations, this is not my point here.
While static analysis should be considered essential, how this analysis is delivered definitely matters. Many of us have heard of “shift-left”. In that context, your IDE is the first place you should get your code analyzed. In this regard, we offer SonarLint. It brings, for free, the benefit of the Sonar experience and detection capabilities straight into your IDE.
But your static analysis should not end in your IDE. Once written and checked in your IDE, your code is committed to some repo, often through development branches and pull/merge requests. At this point, the team gets involved. We want to collaborate on the code, prevent unclean code from getting to the code base, and track issues.
That’s precisely where central static analysis tools kick in. For this, we offer SonarQube and SonarCloud.
In their IDE, most developers would have their project set up for building and debugging. At this point, built-in analyzers or even external linters like SonarLint can use this information to analyze your code accurately. Static analysis then comes with no extra pain. This is probably the main reason why at least 40% of developers make use of an IDE analyzer.
Setting up C++ analysis for a central static analysis tool is a whole different story.
Whereas most popular and modern compiled languages have streamlined their build system, modules, and dependency management systems, C++ is still fighting with ancient tooling inherited from C.
Preprocessor macros, header files nightmares, 30+ compilers4 often with their own language extensions, 15+ vastly different build systems5, no widely used dependency management system; any of these components can also be custom-made and unheard of.
it's as if some mischievous spirit set out to ensure every build is unique in irrelevant, yet confounding, ways.
So, there is no universal recipe to understand how a C++ code base is built and hence no way to configure an analysis accordingly. So far, our industry concluded that there is no way to self-configure C++ static analysis. From that perspective, we made the impossible, possible.
Nowadays, all advanced static analysis tools for C++ need to know precisely how to build your software to overcome this inconvenient fact. It can be done in multiple ways. They often rely on monitoring the build process to gather information about the compiler and its arguments.
This information is enough to specify how to interpret your C++ code fully.
On paper, this is bulletproof. In reality, quite a few caveats contribute to making this technique not so universal.
From a user experience perspective, let’s be honest: it is pretty steep and, often, not that smooth. This holds for all vendors.
- You need to understand how the project is built in order to analyze it.
- You will have to touch the CI and that may get messy.
- You need a bit of luck and skills to avoid the multiple caveats of this approach and the tool you use.
Setting up an accurate C++ analysis has never been a piece of cake—at least, not a tasty cake.
Of course, some vendors offer alternative, easier ways for specific cases. But then you need to understand when to use which configuration technique, which does not make it simpler.
What if we had a solution that can analyze almost any C++ project you throw at it without any intervention from the user?
This is the magic that we call "automatic analysis for C++" and you'll find it on SonarCloud.
You can analyze almost any C++ project6 hosted on GitHub in one click. Literally!
No need to wrap your build, use alternate ways, and cope with various caveats.
- You do not need a CI.
- You do not even need to build the project.
- You do not even need to know the project.
- You do not even need a keyboard. A mouse or a smartphone is enough.
In addition, you also get:
- Pull requests decoration and Quality Gates to prevent bad code from getting merged
- Automatic analysis for many other languages, including Java, Python, JS/TS, and C#
On top of that, it is available for free, without any limitation, on SonarCloud for any public repo on GitHub!
You can analyze any public repo on GitHub by forking it and going straight to SonarCloud.
Like every magic trick, you probably want to know what’s behind the scenes.
As a good magician, I will not say much here. There is one fundamental idea making automatic analysis for C++ possible. Contrary to compiling code, you do not need 100% accuracy in understanding the code to produce a valuable and accurate analysis. As a result, we can analyze the source files independently from any other file. We are totally agnostic of any build system or dependency management system. The code and only the code.
We shaped this first version’s scope so that:
- It can give a valuable preview of our C++ analysis in almost every situation.
- In most cases, there is no need to use a manual configuration over automatic analysis.
So, for most users, the answer to the question is yes!
Of course, there are a few cases where you would need to configure your analysis manually. A project requiring test coverage import is such a case.
All these cases are listed and explained in the SonarCloud documentation.
6 C is also supported