Ask an abstract C++ programmer what are the most common errors and you’re likely to hear: null pointers, division by zero, undefined behavior, array overruns, uninitialized variables. But this has little to do with reality. They are rather a set of errors we’ve all heard of or read about in programming courses and books. In practice, it is other errors which consume much effort and time but remain in the shadow of the discussion. Let’s talk a bit about this interesting topic.

As I have already said, programmers are likely to mention that division by zero and uninitialized variable errors are a problem. Sure, such errors do occur, but their importance is exaggerated, to put it mildly.

Due to the specifics of our work, we check a large number of open source projects. Well, relying on my experience of project analysis, I can tell you that division by zero and access to uninitialized memory errors are rather rare.

First, there are very few division errors because it’s not very often you have to divide something in programs. Second, everyone is aware of these errors and checks the divisor’s value rather carefully. Third, compilers are getting better at learning to look for such errors.

The situation is similar with uninitialized variables. People are well aware of this error pattern and write rather tidy code in general. Fortunately, many people agree that a variable should have as small a scope as possible, and that it is good style to declare a variable immediately with its initialization. Also, compilers have become smart enough to warn of the use of an uninitialized variable.

All in all, such errors in real projects are rare. Why do they occur so often? Perhaps programmers encountered these errors when they were just learning to program. The scenario of using an uninitialized variable in the very first programs is quite probable. The first experience leaves the most indelible mark :). Another possibility is that fears have their roots in old books, when even more dangerous programming languages were used and compilers were extremely weak in terms of detecting potential flaws.

Well, what about undefined behavior, null pointers, array overruns? There really are a lot of such errors and they are often quite hard to detect. So worries about them are quite reasonable. Look how many null pointer errors alone we have collected in open-source projects: V522, V595, V757, V769, V1004, etc. Programmers expect problems with it and they really face these very problems. So let’s skip to the most interesting things. These are the bugs that don’t get talked about, but there are a hell of a lot of them.

I argue that there are vast classes of mistakes that cause a lot of problems, but are undeservedly underreported. We’re talking about typos.

Ha, the reader will say. Well, I know about typos. What is the secret and mystery here? There is no secret, but there is a clear underestimation of the problem. You may see it at least from the way test sets for estimating analyzers’ work are built.

The topic of typos is bypassed. The reason might be that the misprints problem is formulated more poorly than, say, zero pointers. A null pointer is simple and clear. If there is a way of program execution when a pointer turns out to be a null pointer and then is dereferenced, it is easy to describe it in the book and it is clear how to look for such errors using static code analysis.

What is a typo? Ohh. Good question. It’s the wrong variable name, it’s the confusion in parentheses, it’s the wrong array index, it’s the failed Copy-Paste, and even the confusion between & and &&. We have thousands of these errors written out. I even find it hard to give any specific links, but if you dig around here, you can see these countless variations of typos.

Apparently, because the misprints cannot be described or diagnosed well, they slip through the fingers of book authors and analyzer developers. Ordinary programmers also cannot see such errors because they are too simple. A person simply cannot take a typo seriously.