# Terrible tips for a C\+\+ developer: 2026 edition, Part 1

We're introducing an updated edition of the terrible tips for a C\+\+ developer book\. We'll be posting it on our blog in parts\. The book includes a total of 60 tips\.

Each part will feature a list of "tips" that developers really shouldn't follow\. Each tip comes with an explanation of why it's bad, as well as a breakdown of its less obvious aspects\. This series is designed to help beginner programmers learn the ropes, while entertaining experienced developers with some of the more unexpected C\+\+ quirks\.

![1426_terrible_tips_pt1/image1.png](https://import.viva64.com/docx/blog/1426_terrible_tips_pt1/image1.png)

## Foreword

The first edition of the book came out in 2023\. Three years later, I decided that the time had come for an updated edition\. I've fixed errors, expanded or rewritten some chapters, and added new topics I'd like to cover, such as secure software development \(SSD\) and AI\-generated code\.

**How did the book appear?**

Originally, I wanted to write a book about techniques for creating high\-quality code\. I wanted to cover topics such as code formatting and what to look for during code reviews\. I also wished to discuss which new C\+\+ features developers should definitely adopt and which ones might be questionable\. However, I got caught up in another topic by accident and decided to go with the flow\.

It all started with a humorous post on Habr, where I came up with a few pieces of bad advice and invited readers to contribute their own\. The community liked the idea and shared lots of suggestions for writing truly terrible code\. I picked some of those tips, added my own, and posted them in an article\. I also explained some tips that beginners might not realise could be harmful\. That's how the idea took shape and evolved into this book\.

I enjoyed writing about what not to do rather than how to do things right\. It was a nice change of pace, if nothing else\. I'm tired of writing traditional educational materials, particularly those on secure software development\. Sometimes, I just want to let loose, add some humour and see where my thoughts take me\.

I've spent so many years studying software bugs and writing about how to avoid them\. This is closely linked to my work on developing and promoting PVS\-Studio, a static code analyzer\.

Static analyzers detect code fragments that are likely to contain bugs or violate a project's coding standards\. PVS\-Studio is one such tool\. The tool's mascot, Cody the unicorn, will make a few more appearances throughout the book\.

I use open\-source projects to show the types of bugs and potential vulnerabilities this methodology can uncover\. Even more importantly, though, I try to explain how to write code that's free of such errors\. In other words, I keep coming back to the same topics: how to properly format code, what makes a good comment, why code reviews matter, and so on\.

So, I decided to expand on the concept of terrible tips and turn it into a book\. However, very little remains from the original list of bad advice, aside from the idea itself\. I removed or replaced anything that was too obvious or uninteresting, and I added a lot of theory that will benefit both beginners and seasoned developers\. The second edition also covers a wider range of topics\.

As you might expect, I learned what good and bad code looks like by developing PVS\-Studio and studying the bugs it detected\. This is why the analyzer will occasionally appear in various chapters\. I've spent so much time working with static analysis that I immediately think of real\-world bugs when I hear about certain topics\. I can't resist sharing these examples to make my points more convincing\. If they help illustrate the point, why not mention them?

I wrote this book with love and respect for my readers, and I didn't use AI to generate the text\. I hope you enjoy reading it\!

## Terrible tip N1\. Only C\+\+

**Real developers code only in C\+\+\!**

There's nothing wrong with writing code in C\+\+\. There are many projects in the world written in C\+\+\. Take a look at [this list from Bjarne Stroustrup's homepage](https://www.stroustrup.com/applications.html), for example\.

> "Here is a list of systems, applications, and libraries that are completely or mostly written in C\+\+\. Naturally, this is not intended to be a complete list\. In fact, I couldn't list a 1000th of all major C\+\+ programs if I tried, and this list holds maybe 1000th of the ones I have heard of\. It is a list of systems, applications, and libraries that a reader might have some familiarity with, that might give a novice an idea what is being done with C\+\+, or that I simply thought "cool"\.
>
> Bjarne Stroustrup

It's bad when developers use C\+\+ just because it's "cool" or because it's the only language the team knows\.

The variety of programming languages reflects the wide range of tasks software developers encounter\. Different languages help developers solve different types of problems\.

C\+\+ is a versatile programming language\. However, being versatile doesn't guarantee that particular applications will be implemented quickly and easily\. Some languages may be better suited to certain projects than others\.

It's fine for a team to develop a small utility in C\+\+, even if another language would be more efficient\. The time and effort required to learn a new language may be greater than the benefits it provides\.

However, it's a different story when the team needs to build a large project\. At that point, it's worth taking a step back and asking: Is C\+\+, a language we know well, really the most efficient choice for this project? Would another language be a better fit?

If using another language would clearly be more efficient, it may make sense for the team to invest time in learning it\. In the long run, this could greatly reduce development and maintenance costs\. As an alternative, the team could hand the project over to another group that uses a more suitable language for the task\.

So, when should you choose C\+\+? C and C\+\+ have been the most successful languages for system programming tasks, such as operating systems, drivers, compilers, and DBMSs\. They're also well\-suited for environments with limited resources, such as memory and CPU time\.

When we talk about resource constraints, microcontrollers are probably the first thing that comes to mind\. Yes, C\+\+ is widely used in embedded systems and the IoT \(Internet of Things\)\.

However, resource constraints can also take other forms\. C\+\+ is also used to develop applications for high\-performance computing clusters with enormous amounts of memory\. So, where's the catch? In this case, the constraints are the cost of the necessary hardware and the electricity required to power the data centers\. Even a small improvement in code efficiency—just 5–20%—can result in significant savings\.

Another story that comes to mind is how Disney Studios reduced rendering time by developing its own C\+\+ algorithms that used SIMD and specialized data structures\.

To sum up, C\+\+ is an excellent language for building highly efficient applications\. The trade\-off is a steep learning curve and the necessity of strict discipline when writing code\. Choose C\+\+ when you genuinely need it\.

You might be tempted to argue that developers no longer need an in\-depth knowledge of the language because generative AI \(GenAI\) can now write code for them\. So, why not choose C\+\+ and start generating fast code right away? With that, we come to our next terrible tip\.

## Terrible tip N2\. Don't learn C\+\+; command it with vibe coding

**You no longer need an in\-depth knowledge of programming languages\. Thanks to GenAI, you can write efficient C\+\+ applications without having to spend time learning the language\.**

Writing about GenAI is a thankless task\. AI\-driven development paradigms are evolving and changing so rapidly that something may already be outdated by the time I finish writing this book\. And by the time it's printed, I'll probably wish I'd written this chapter differently\. Still, I'll try to express an important idea that will survive the AI gold rush\.

Without understanding how the generated code works, developers risk falling into two traps:

1. They won't be able to tell efficient code from inefficient one\.
1. They'll encounter an error they can't fix\. They may try to fix it by repeatedly regenerating the code, but that might not work either\.

While these problems can arise when working with any programming language, they're particularly pronounced in C\+\+\. C\+\+'s high performance comes at the price of its complexity\. Writing inefficient C\+\+ code is like using a microscope to hammer a nail\.

In this chapter, we'll focus on the first point\. The next chapter will take a closer look at errors and dangers of placing too much trust in AI\-generated code\.

GenAI can create code that looks elegant and optimized\. Is it really, though? Only a C\+\+ expert with an in\-depth understanding of the language is qualified to verify the soundness of the project's architecture, as well as the efficiency of its algorithms and code\. Without such expertise, the project can quickly go off track\.

For example, let's look at a small function generated with Claude Opus\. The comment above `IsSpanBlank` promises that the code is structured to make the compiler's job easier when vectorizing it, for example, by using SSE instructions\.

The following example comes from the article "[Let's check vibe code that acts like optimized C\+\+ but is actually a mess](https://pvs-studio.com/en/blog/posts/cpp/1366/)"\. The article also provides other examples that demonstrate why developers need to manually check AI\-generated code\. Otherwise, code will become complex, bloated, and slow\. I recommend taking a few minutes to read through it: it's entertaining and educational\.

The key to the optimization is that it handles multiple elements at once to see if they have space characters:

```cpp
// Check if a span contains only blank characters
// (space, tab, \r, \n)
// SIMD-friendly: processes 8 bytes at a time
inline bool IsSpanBlank(const char* data, size_t len) {
  size_t i = 0;
  // Process 8 bytes at a time
  for (; i + 8 <= len; i += 8) {
    // For each byte, check if it's NOT a blank character
    // Blank chars: space(0x20), tab(0x09), \n(0x0A), \r(0x0D)
    bool all_blank = true;
    for (size_t j = 0; j < 8; ++j) {
      unsigned char c = static_cast<unsigned char>(data[i + j]);
      bool is_blank = (c == ' ' || c == '\t' ||
                       c == '\n' || c == '\r');
      all_blank = all_blank && is_blank;
    }
    if (!all_blank) return false;
  }
  // Handle remaining bytes
  for (; i < len; ++i) {
    unsigned char c = static_cast<unsigned char>(data[i]);
    if (c != ' ' && c != '\t' && c != '\n' && c != '\r') {
      return false;
    }
  }
  return true;
}
```

The code makes it seem like the AI knows what it's doing\. The inner loop handles eight characters at a time and can be optimized using SIMD instructions\. A separate simple loop handles the remaining characters\.

To me, it looked suspicious that the bytes are still being handled sequentially and that the nested loop doesn't add anything useful\. I think this code is just as good as the simplest way to implement it:

```cpp
bool IsSpanBlank_Simple(const char* data, size_t len) {
  for (size_t i = 0; i < len; ++i) {
    unsigned char c = static_cast<unsigned char>(data[i]);
    if (c != ' ' && c != '\t' && c != '\n' && c != '\r') {
      return false;
    }
  }
  return true;
}
```

I'd write the code this way\. Had I known this was a bottleneck and I absolutely had to optimize the code as much as possible, I would've looked for an intrinsic\-based solution\.

I wouldn't try any other option, such as one with a nested loop\. I know a thing or two about optimization, but not enough to dare write fancy code just to give the compiler a hint\.

One could say, "You're weak\! Claude Opus did it— it came up with the smarter version\!"

Let's compare performance\. My colleague Phillip, who's an expert on C\+\+, conducted a small experiment with GCC and Clang:

* We create the same dataset for both benchmarks: we generate 1,000,000 strings of random lengths, with arbitrary content, ranging from 1 to 127 characters\. The calculations don't include set generation\.
* We feed a dataset to the algorithm and determine whether each string contains spaces\. We measure the total time\.

In both cases, the code is compiled with aggressive `-O3` optimizations\. As you can see, in both compilers, the simple function performs better than the one with the nested loop\.

![1426_terrible_tips_pt1/image2.png](https://import.viva64.com/docx/blog/1426_terrible_tips_pt1/image2.png)

Shall we specify a magic optimization key to better optimize the vibe code? That key doesn't exist\. And even if it does, the compiler will generate an equally efficient version from simple code with a single loop, even without any hints\.

Along with my colleague, I also experimented with the two previously explored options and three new algorithm variants\. I used the MSVC compiler\. Let's take a look at the measurement results\.

First, someone suggested improving the code by replacing the original `||` with `|`\. In our case, short\-circuit evaluation only causes more harm than good\. Here's an improved check:

```cpp
bool is_blank = (c == ' ' | c == '\t' | c == '\n' | c == '\r');
```

Secondly, I asked DeepSeek\. It suggested an optimization approach based on bitwise operations:

```cpp
bool IsSpanBlank_Deepseek(const char* data, size_t len) noexcept {
  // Creating a bitmask for valid characters
  // Using a 128-bit mask for ASCII
  static constexpr uint64_t blank_mask_low = []() {
      uint64_t mask = 0;
      mask |= 1ULL << ' ';
      mask |= 1ULL << '\t';
      mask |= 1ULL << '\n';
      mask |= 1ULL << '\r';
      return mask;
  }();
    
  for (size_t i = 0; i < len; ++i) {
    unsigned char uc = static_cast<unsigned char>(data[i]);
    if (uc >= 64) return false;  // All blank characters in ASCII < 64
    if (!((blank_mask_low >> uc) & 1)) return false;
  }
  return true;
}
```

Finally, I asked DeepSeek for an optimized function that truly takes advantage of vectorization\. Here's what I got:

```cpp
bool IsSpanBlank_Deepseek_SSE(const char* data, size_t len) noexcept {
  // Creating vectors with valid characters
  const __m128i space = _mm_set1_epi8(' ');
  const __m128i tab = _mm_set1_epi8('\t');
  const __m128i newline = _mm_set1_epi8('\n');
  const __m128i carriage = _mm_set1_epi8('\r');
    
  size_t i = 0;
    
  // Processing 16 bytes at a time
  for (; i + 15 < len; i += 16) {
    __m128i chunk =
      _mm_loadu_si128(reinterpret_cast<const __m128i*>(data + i));
       
    // Checking that each byte matches one of the valid values
    __m128i eq_space = _mm_cmpeq_epi8(chunk, space);
    __m128i eq_tab = _mm_cmpeq_epi8(chunk, tab);
    __m128i eq_nl = _mm_cmpeq_epi8(chunk, newline);
    __m128i eq_cr = _mm_cmpeq_epi8(chunk, carriage);
       
    __m128i is_blank = _mm_or_si128(_mm_or_si128(eq_space, eq_tab),
                                         _mm_or_si128(eq_nl, eq_cr));
        
    // Obtaining the mask and checking it
    int mask = _mm_movemask_epi8(is_blank);
    if (mask != 0xFFFF) return false;
}
    
  // Processing the remainder
  for (; i < len; ++i) {
    char c = data[i];
    if (c != ' ' && c != '\t' && c != '\n' && c != '\r') return false;
  }
    
  return true;
}
```

Now, the results\. Although 32\-bit builds are no longer relevant, I ran it just for the sake of curiosity\. Testing was performed on a 212\-megabyte array filled with random space characters\. Thread execution is bound to a single preheated core\.

```cpp
Win32:
The simplest option with a single loop:                          1.39 s.
The original "optimized code" with a nested loop:                1.86 s.
The original version but the || operators were replaced with | : 0.351 s.
Deepseek's implementation with bitmask optimization:             0.817 s.
Deepseek's implementation with SSE2 intrinsic optimization:      0.0449 s.

Win64:
The simplest option with a single loop:                          0.175 s.
The original "optimized code" with a nested loop:                0.309 s.
The original version but the || operators were replaced with | : 0.253 s.
Deepseek's implementation with bitmask optimization:             0.207 s.
Deepseek's implementation with SSE2 intrinsic optimization:      0.0396 s.
```

Clearly, the 64\-bit code is much more efficient, except when SSE2 is involved\. Even then, though, everything runs quickly\.

**The code Claude Opus generated for the markus project is the worst of all the options\.**

Not only is the simplest implementation with a regular loop faster, it's also shorter\. The extra code lines only made things worse\.

Although intrinsic code is in the lead, this comes at the cost of limited portability\.

Some might say I'm worrying for nothing\. Yes, Claude Opus chose a poor implementation, but DeepSeek offered a perfectly good, fast, and portable one\.

I agree\. However, we see some poorly written code in the project\. It looks optimized, but it isn't\. The issue remains unresolved\. This case requires an expert who understands it and can come up with a different solution\. Knowing C\+\+ well isn't enough to be one\. It's also necessary to have experience writing and optimizing applications\.

## Terrible tip N3\. Reading books is no longer relevant

**Reading fundamental books on C\+\+ is a waste of time\. Educational videos are enough, GenAI will help with everything else\.**

This chapter is for those who are just getting started with programming\. Experienced developers can skip it\. Or they can read it anyway and see how much it resonates with their own thoughts and experiences\.

The point of the previous chapter wasn't to discourage the use of GenAI\. Instead, the focus is on understanding and controlling whether the generated code meets the necessary quality, reliability, and security standards\. This brings us to the question of learning programming theory and gaining hands\-on experience\.

The question of how to learn programming has always existed\. The issue has become even more pressing today because of the illusion that programming technologies are evolving faster than ever before\. In their articles, GenAI and vibe\-coding enthusiasts openly claim that knowledge acquired just a year ago is obsolete and that developers should use AI agents differently\. Maybe the problem is that what they had wasn't real knowledge to begin with\.

Fundamental knowledge of system design, OOP, programming languages, team management, and so on remains just as relevant as ever\.

However, all the hype surrounding GenAI may cause inexperienced developers to believe that truly investing in self\-education is pointless since everything will become obsolete in just a year\. Instead, they should focus on quickly learning the basics of whatever is new while GenAI successfully implements everything they could ever hope to\.

![1426_terrible_tips_pt1/image3.png](https://import.viva64.com/docx/blog/1426_terrible_tips_pt1/image3.png)

Ensuring that everything works correctly and efficiently requires understanding of the process\. Sometimes, it's optional: for example, when building an MVP or working on a pet project\. However, I'm referring to professional software development, where tasks and their complexity extend well beyond the scope of quickly generating some code\. GenAI enthusiasts who write articles about it often don't even understand the problems we're dealing with\. They see the code and think, "There it is\. What more could you want?" I like this quote that captures the idea:

> "And that, in my opinion, is one of the main problems right now\. Those who don't fully understand programming are now confidently telling everyone else how to do it\."
>
> Mikhail Larchenko\.

For anyone getting started in programming, my advice is to learn and practice writing code on your own\. These skills are necessary regardless of whether the code is AI\-generated or written by a human developer\. That distinction doesn't matter\. What matters is having experts who can take responsibility for the results\!

What pitfalls await those who want to learn programming today?

* When studying theory: the short\-form video format that the social media era has made so prevalent\.
* When practicing: the temptation to turn to GenAI right away\.

### Theory

I'm all for reading books on programming\. However, I can't downplay the benefits of tutorial videos and other learning methods\. I'd enjoy watching a talk from a C\+\+ conference\.

The problem lies in the growing preference for video\-based content\. I've noticed that reading programming books has gone out of fashion\.

Educational videos have two major drawbacks:

1. They don't encourage you to stop and reflect on what you've seen and heard\. You can pause or rewind, but neither feels as convenient or natural as reading a book\. When studying C\+\+ from books, I would often reread paragraphs or go through example code again, taking my time\. In other words, I'm talking about attentive and thoughtful reading\. You can use videos to achieve the same results, but it doesn't work quite the same way\. You just keep watching, even when you haven't fully understood something\. Sometimes, you even speed up the video\.
1. Unlike books, educational videos lack a comprehensive approach to information\. I can't imagine how anyone could fit the same amount of knowledge into a video in an accessible way as, for example, Bjarne Stroustrup presents across 1,200 pages in "The C\+\+ Programming Language" \(4th edition\)\.

If approached with the same attention to detail as books, a video would look something like this\.\.\.

![1426_terrible_tips_pt1/image4.png](https://import.viva64.com/docx/blog/1426_terrible_tips_pt1/image4.png)

Videos are a demanding format to learn from\. In my opinion, they're most effective when used to reinforce existing knowledge\. They're useful when they build on a solid foundation acquired through books\. Otherwise, they create a fragmented illusion of knowledge\. A developer may appear to know their way around programming, but these kinds of knowledge gaps will eventually catch up with them and their employer\.

Even before the GenAI era, I've encountered programmers like this\. At first glance, they seem incredibly talented\. They can quickly build something at a hackathon using trendy libraries or create something stunning with a game engine\. It all looks like magic, especially if you've never worked with those libraries yourself\. However, this illusion quickly fades when they struggle with a real\-world task because they're unaware of basic algorithms or the intricacies of their programming language\. Now, in the age of GenAI, things are only going to get worse\.

So, what's the problem if someone doesn't know everything, yet still manages to get things done? The problem is inefficiency and limited capabilities\. A lack of knowledge can lead people to adopt strange, highly inefficient approaches\. They may rely on vibe coding or search Stack Overflow for ready\-made solutions\. However, sooner or later, they'll reach a point where they can't solve the problems they're facing\. The line isn't visible, but it's there\.

By the way, I ask candidates during job interviews which C\+\+ programming books they've read\. Not having read any books doesn't automatically disqualify someone, but it does raise a red flag\.

### Practice

A beginner who uses GenAI to write code from day one skips the gradual learning process from syntax to architecture\. They get a working result right away without first understanding why one approach works better than another\. They neither learn from their mistakes nor reflect on their actions\.

Getting quick, working results is exciting and motivating\. However, not understanding how the system works as a whole is a big issue\. It'll catch up with them later when they finally have to figure out why AI generated something that doesn't work\.

When you learn programming, with GenAI writing code for you, you don't have to track down bugs through debugging or understand the intricacies of how an algorithm works\. Instead, you're encouraged to fix issues by simply regenerating the code\. In a real\-world project, that lack of debugging experience will eventually lead to a dead end\.

It's up to you to decide what to do and whether to take my advice\. And my friendly advice is to spend less time reading about the AI hype\. Explore classic programming books, practice writing code on your own, and make it work\. We'll always need experts who truly understand what they're doing\.

### A look back

Sometimes it's interesting to look at something new through the lens of the past\. Here's a quote from a wonderful book "Code Complete" by Steve McConnell \(second edition, ISBN 978\-5\-7502\-0064\-1\)\.

> "Over the past several decades programmers have seen numerous tools that were supposed to eliminate programming\. First it was third generation languages\. Then it was fourth generation languages\. Then it was automatic programming\. Then it was CASE tools\. Then it was visual programming\. Each of these advances spun off valuable, incremental improvements to computer programming—and collectively they have made programming unrecognizable to anyone who learned programming before these advances\. But none of these innovations succeeded in eliminating programming\."

\.\.\.

> "We will always need people who can bridge the gap between the real world problem to be solved and the computer that is supposed to be solving the problem\. These people will be called programmers regardless of whether we're manipulating machine registers in assembler or dialog boxes in Visual Basic\. As long as we have computers, we'll need people who tell the computers what to do, and that activity will be called programming\. When you hear a tool vendor claim, "This new tool will eliminate computer programming"—run\! Or at least smile to yourself at the vendor's naive optimism\."

As they say, Simpsons already did it\. The book was published in 2004\.

## Terrible tip N4\. Tab characters in string literals

**If you need a tab character in a string literal, just press the Tab key\. Leave \\t to the nerds\. Don't sweat it\.**

I'm talking about string literals where tabs separate words:

```cpp
const char str[] = "AAA\tBBB\tCCC";
```

It'd seem there's no other way to do it\. Yet, sometimes, developers just carelessly press the `Tab` key instead of using `\t`\. This thing happens even in real projects\.

Such code compiles and even works\. However, explicitly using the tab character isn't recommended for the following reasons:

1. Literals may have spaces instead of tabs, which depends on the editor settings\. Although, the code looks like there's a tab character\.
1. The developer who maintains the code won't immediately understand whether tabs or spaces are used as delimiters\.
1. During refactoring \(or using code autoformatting utilities\), tabs may turn into spaces, which affects the program's behavior\.

Moreover, once I saw the code similar to this one in a real application:

```cpp
  const char table[] = "\
bla-bla-bla bla-bla-bla bla-bla-bla-bla-bla \n\
      bla-bla-bla       bla-bla-bla\n\
          %s                %d\n\
          %s                %d\n\
          %s                %d\n\
";
  printf(table, "X", 1, "Foo", 2, "Time", 3);
```

The '\\' character splits the string into parts\. Explicit tab characters are mixed with space characters\. Unfortunately, I don't know how to show it here, but trust me, the code looked bizarre\. On top of that, the alignment started at the beginning of the screen\. Bingo\! I've seen lots of strange things while developing a code analyzer\!

Explicit tabs added using the `Tab` key are very easy to "lose"\. If they're replaced with spaces during refactoring or auto\-formatting, values will no longer print in a column:

```cpp
bla-bla-bla bla-bla-bla bla-bla-bla-bla-bla
     bla-bla-bla       bla-bla-bla
         X                  1
         Foo                  2
         Time                  3
```

The code should've been formatted as follows:

```cpp
const char table[] =
  "bla-bla-bla bla-bla-bla bla-bla-bla-bla-bla\n"
  "     bla-bla-bla       bla-bla-bla\n"
  "         %s\t            %d\n"
  "         %s\t            %d\n"
  "         %s\t            %d\n";

printf(table, "X", 1, "Foo", 2, "Time", 3);
```

Tab characters ensure that the second column is aligned, regardless of the name length in the first column \(`X`, `Foo`, `Time`\)\. These names are expected to be short—fewer than eight characters long\. The fixed code will print:

```cpp
bla-bla-bla bla-bla-bla bla-bla-bla-bla-bla
     bla-bla-bla       bla-bla-bla
         X                 1
         Foo               2
         Time              3
```

Some people might wonder why I'm talking about such simple and obvious things\. Moreover, even the fixed code is a bit off and doesn't look like a good example for the book\. However, since I could clearly see tab characters in the lines, I think it's worth mentioning\. This fix is better than having someone repeatedly pressing the `Tab` key without understanding what's wrong with it\.

**Author: Andrey Karpov**

Andrey has over 19 years of experience with static code analysis and software quality\. The author of numerous articles on writing high\-quality code in C\+\+\. Andrey Karpov has been honored with the Microsoft MVP award in the Developer Technologies category from 2011 to 2021\. Andrey is a co\-founder of the PVS\-Studio project\. He has long been the company's CTO and was involved in the development of the C\+\+ analyzer core\. Andrey is currently the Chief Business Development Officer \(CBDO\), responsible for educational marketing\.

## To be continued

In upcoming posts, you'll find more terrible tips for C\+\+ programmers\. Make sure you [subscribe to our blog newsletter](https://pvs-studio.com/en/subscribe/) to stay up to date with all our latest content\!