To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

Why Static Analysis Can Improve a Compl…

Why Static Analysis Can Improve a Complex C++ Codebase

Aug 03 2019

Gradually and imperceptibly we get the situation when C++ projects' complexity becomes extreme. Unfortunately, now a C++ programmer can't be on his own.


Note. This article was first published by me on the blog Fluent C++: Why Static Analysis Can Improve a Complex C++ Codebase.

First, there is so much code that it is no longer possible to have at least a couple of programmers per project who know the whole project. For example, earlier the Linux 1.0.0 kernel contained about 176,000 lines of code. That's a lot, but it was possible to review the entire code and understand the general principles of its work for a couple of weeks, having a coffee machine nearby. Nevertheless, if you take the Linux 5.0.0 kernel, the size of the code base is already about 26 million lines of code. The kernel code is 150 times larger than it used to be. You can only choose a few parts of the project and take part in their development. You can't settle down and figure out exactly how it works, what are the interconnections between different parts of code.

Secondly, the C++ language continues to develop rapidly. On the one hand, it is good, as new constructions appear which allow writing more compact and secure code. On the other hand, due to backward compatibility, old large projects become heterogeneous. Old and new approaches to code writing intertwine in them. Here comes the analogy with the rings on the tree cut. Because of this, it is becoming more and more difficult to immerse yourself in C++ projects every year. A developer has to know what's what in code both written in "C with classes" style and in modern approaches (lambdas, move semantics and so on). It takes a long time to fully dig into C++.

Since projects still have to be developed, people begin to write code in C++, whereas they haven't fully studied all its nuances. This leads to additional defects. Nevertheless, it's irrational to just stay and wait when all developers will flawlessly know C++.

Is the situation hopeless? No. A new class of tools comes to the rescue: static code analyzers. Here many worldly-wise programmers twist the lips, as if I just palmed on a lemon :). Like, we know all your linters... Lots of warnings - great boast, small roast... And what is the new class of tools?! We ran linters even 20 years ago!

Yet I would venture to say that this is a new class of tools. What was 10-20 years ago is not the kind of tools that are now called static analyzers. First, I'm not talking about tools aimed at code formatting. They're also static analysis tools, but we're talking about identifying bugs in the code. Second, today's tools use sophisticated analysis technologies, taking into account the relationships between different functions and virtually executing certain parts of code. These are not those 20-year-old linters built on regular expressions. By the way, a normal static analyzer can not be done on regular expressions. Technologies like data flow analysis, automatic methods annotation, symbolic execution and others are used to find errors.

These are not just abstract words, but it's the reality that I can observe, being one of the founders of the PVS-Studio tool. Check out this article to see what helps the analyzers find the most exciting errors.

More importantly, modern static analyzers have extensive knowledge of error patterns. Analyzers know more than even professional developers. It has became too difficult to take into account and remember all the nuances when writing code. For instance, if you haven't specifically read about it, you'll never guess that calls to memset function for clearing private data sometimes disappear, as from a compiler's point of view, a call to memset function is redundant. Meanwhile, it is a serious security defect CWE-14 that is detected literally everywhere. Or, for example, if you haven't heard about that guideline, how would you know that it is dangerous to add an element to a container this way?

std::vector<std::unique_ptr<MyType>> v;
v.emplace_back(new MyType(123));

I think, not everyone will immediately realize that such code is potentially dangerous and can lead to memory leaks.

In addition to extensive knowledge of patterns, static analyzers are infinitely attentive and never get tired. For example, unlike humans, they are not too lazy to look into header files to make sure that isspace and sprintf are actual functions, but not insane macros which spoil everything. Such cases demonstrate the complexity of finding bugs in large projects: something changes in one place, and breaks down in another.

I'm sure that soon static analysis will become an intrinsic part of DevOps - it will be as natural and necessary as usage of version control system. It is already gradually happening at development conferences, where static analysis is increasingly mentioned as one of the first lines of defense to fight against bugs.

Static analysis acts as a kind of rough cleaning filter. It is inefficient to look for stupid errors and typos using unit tests or manual testing. It's much faster and cheaper to fix them right after you've written code, using static analysis to detect problems. This idea, as well as the importance of regular application of the analyzer, is well described in the article "Introduce static analysis into the process, don't look for bugs with it."

Someone may say that there is no point in special tools, as compilers learn how to perform such static checks as well. Yes, it's true. However, static analyzers are also on the go and leave behind compilers as specialized tools. For example, every time when we check LLVM, we find errors there using PVS-Studio.

The world offers a large number of static code analysis tools. As they say, choose by your preference.

In summary, if you want to find a lot of bugs and potential vulnerabilities while you're writing code, and increase the quality of your codebase, use static code analyzers!

Popular related articles
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →