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.

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, 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:

• They won’t be able to tell efficient code from inefficient one.
• 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”. 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:

// 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:

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.

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:

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

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

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:

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.

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.

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:

• 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.
• 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…

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:

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:

• Literals may have spaces instead of tabs, which depends on the editor settings. Although, the code looks like there’s a tab character.
• The developer who maintains the code won’t immediately understand whether tabs or spaces are used as delimiters.
• 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:

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:

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:

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:

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 to stay up to date with all our latest content!

Follow Andrey Karpov on LinkedIn and X.

Terrible tips for a C++ developer: 2026 edition, Part 1 was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

We published and translated this article with the copyright holder’s permission. The author is Kekchpek.

Compilation and execution

First, we’ll compare how our code is compiled and executed in .NET and Unity3D. In .NET, the process is fairly straightforward and transparent. The C# code is first compiled into IL, then packaged into DLL or EXE files, and finally executed by a virtual machine. However, this approach has one drawback that has long posed a major obstacle to cross-platform development for C# programmers: dependence on a virtual machine. Today’s .NET is nothing like its predecessor, .NET Framework, which was exclusively Windows-based. Before .NET emerged, the most popular solution for cross-platform development was the Mono virtual machine, which could also execute IL code and served as an alternative to .NET Framework.

Unity3D originally ran on the Mono virtual machine. Today, Mono remains one of the options for running C# code in Unity3D. The second option is IL2CPP, a newer technology developed by Unity Technologies, which is gradually replacing Mono. Code compiled with IL2CPP runs faster and doesn’t require a pre-installed or bundled virtual machine. As for how IL2CPP works, its name speaks for itself. Roslyn first compiles C# into IL, which is then translated into C++. Finally, the C++ compiler converts the code into machine code. The C++ compiler varies depending on the target platform. In terms of C#, however, the code behaves much like it does in .NET. Unity3D uses a very similar garbage collector, standard library, and so on.

So, although the compilation process differs, the average developer won’t notice much difference. One drawback is that it’s nearly impossible to predict how the code will compile on different platforms. IL2CPP bugs are certainly a possibility, but encountering them is as unlikely as running into bugs in .NET.

Any C# DLL libraries that contains IL can be used in Unity3D. During compilation, Unity runs the code through IL2CPP and recompiles it into C++.

However, things aren’t that simple when it comes to C# versions. Unity uses C# 9, which is rather outdated, and even that version lacks support for certain features. You can read more about it here.

Libraries and compatibility

As I mentioned earlier, libraries written in C# can be compiled for different platforms using IL2CPP, but there are some limitations. Unity supports compatibility with .NET Framework and .NET Standard libraries. However, that doesn’t mean libraries compiled for .NET won’t work. They might work, but not all of them will. It depends on whether their IL code contains anything that Unity3D can’t translate into C++.

The standard library works in Unity3D, but with a few caveats. In other words, we have access to all the features of standard C#, including collections, concurrency, Tasks, LINQ, networking, and more. However, Thread and Task (when used to run separate threads), for example, won't work in WebGL builds (games that run in browsers). This is one of the most obvious limitations, but one may occasionally encounter others related to the specifics of a particular platform.

From a coding perspective, Unity3D acts as an extensive library within the UnityEngine namespace. The UnityEditor namespace also exists that contains the editor API, which enables developers customize windows, builds, plugins, and more.

How to organize code into modules

In .NET, we’re used to organizing code into separate modules via .sln and .csproj files. Unity3D has them too, but we can't work with them directly. Unity3D creates .sln and .csproj files, purely for the developers' convenience. This allows popular IDEs to provide proper syntax highlighting, error detection, and other useful features. Unity itself doesn't rely on the contents of .sln or .csproj files at any stage of the project build process. As a result, one common mistake beginners make is adding a library via their IDE. This only modifies the .csproj file, but Unity remains unaware of the change. So, when a dev tries to compile the project, Unity starts throwing errors even though the IDE shows no errors at all.

To control how Unity3D splits code into modules and what properties those modules have, we need to use Unity’s built-in tools. The main feature we’ll work with here is Assembly Definition, Unity’s equivalent of a .csproj file in .NET. To use Assembly Definition, we need to create an .asmdef file in one of the project folders. We can do this via the Unity graphical interface. Once we create the file, Unity treats all .cs files in that folder and its subfolders as a separate module. It generates a dedicated .csproj file for this code and enables us to specify dependencies required by that particular module. We can also use the module as a dependency. We configure everything using Unity3D's graphical interface, and Unity reflects those settings in the generated .csproj files.

By default, we don’t create any .asmdef files, Unity automatically divides code into four modules based on the names of the folders containing the .cs files:

• Assembly-CSharp-Editor-firstpass: the “*/Standard Assets/**/Editor”, “*/Pro Standard Assets/**/Editor” and “*/Plugins/**/Editor” folders
• Assembly-CSharp-firstpass: the “*/Standard Assets”, “*/Pro Standard Assets” and “*/Plugins” folders
• Assembly-CSharp-Editor: the “*/Editor” folders
• Assembly-CSharp: any other folder

Using Assembly Definitions is generally considered a good practice, though not every project has them. The key point to keep in mind is the difference between the Editor and Runtime modules. Editor contains code that runs only in the Unity editor and doesn’t make it into the game build. Developers usually use this code to create additional tools for game designers, artists, and programmers. We can specify in any Assembly Definition that it’s intended only for the editor.

How to integrate third-party libraries

The easiest way to add a third-party library is to simply copy its DLL into the project folder. Unity automatically scans the project folder for DLLs and adds them as dependencies to the generated .csproj files. In the Assembly Definition settings, we can explicitly specify which DLLs to include as dependencies and which to exclude.

We can also directly add source code instead of using DLLs. This might seem a little strange to a .NET developer, but it’s actually a fairly common way to distribute plugins and SDKs for Unity3D. Unity even has a dedicated packaging mechanism called .unitypackage. These files simplify the distribution of assets that need to be imported into specific parts of a project. Usually, when we want to download some open-source SDK, we get a .unitypackage file from GitHub and open it in the Unity editor. The editor adds the necessary source files to the project or updates existing ones, first enabling a developer to review the package contents and choose which files to import. Some SDKs even offer to remove outdated files from previous versions after importing the .unitypackage. However, I'm not sure whether this feature is built into the Unity editor or if SDK developers implemented it themselves.

A more convenient way to manage dependencies is the Unity Package Manager. It’s a package manager similar to npm, with a graphical interface built into the Unity Editor. As with npm, each package used in the project has a package.json file that describes the package and its dependencies. Every package stores this file in its root directory.

The project itself, however, uses manifest.json instead of package.json, unlike npm. Despite the different name, manifest.json serves a similar purpose: it lists the project's dependencies and the package registries from which Unity can retrieve them. Instead of specifying a version, we can provide a link to a GitHub repository or a specific directory within that repository from which Unity should download the dependency. We can also use links to private repositories after configuring Git Credential Manager. Unfortunately, we can specify GitHub links only for dependencies listed in manifest.json.

In other words, we can’t use GitHub links for transitive dependencies (dependencies of other dependencies). This limitation makes managing dependencies less convenient when building infrastructure for large-scale projects. One solution is to create our own package registries and host them in the cloud. These registries can be either private or public.

OpenUPM (Open Unity Package Manager) deserves a special mention. It’s an open package registry for the standard Unity Package Manager where anyone can publish their packages. Most packages distributed as .unitypackage files are also available on OpenUPM. There are also many NuGet packages available on OpenUPM. However, not every NuGet package developer—or developer of any other package—takes the time to publish their packages on OpenUPM. As a result, some packages listed on OpenUPM are just forks of the original projects, tweaked to work with OpenUPM. I'd still advise against dismissing these packages outright.

If you’re a company that takes its code supply chain seriously and carefully controls what goes into its projects, the best approach is to set up your own package registry. You can then validate incoming packages and download everything from that registry. But if you’re developing a small game, a prototype, or if you simply lack the resources to maintain a robust infrastructure for your project, OpenUPM is an excellent solution.

And since this article is aimed at .NET developers, I’d like to mention NuGet for Unity. It’s a plugin that adds a user-friendly interface for managing NuGet packages in Unity. I wouldn’t recommend it, despite having used it a lot myself. The main disadvantage of using NuGet is that it brings multiple sources and dependency managers into a project. This can quickly turn into a major headache in large projects with lots of dependencies. Managing package versions and resolving conflicts between transitive dependencies can be serious challenges.

In short, I recommend using the Unity Package Manager alongside OpenUPM and other package registries wherever possible. Resort to other ways of adding dependencies only when the Unity Package Manager isn’t an option.

Unity3D architecture

Like many game engines, Unity3D uses a tree-based structure to organize objects. An application contains multiple scenes (UnityEngine.Scene), and each of them contains numerous game objects (UnityEngine.GameObject) that act as containers for components (UnityEngine.Component). A component is a basic logical unit that contains executable code. Game objects (GameObject) can also be arranged into hierarchical structures.

Every GameObject has one mandatory component that can't be removed: UnityEngine.Transform. It controls the object's position in the scene and its place in the hierarchy compared to other GameObjects. We can add or remove other components either while working with the scene in the editor or at runtime through code.

Entry point

I believe we have enough context now to move on to the more hands-on topics. The application entry point is the best place to start. In Unity3D, we don’t have access to the Main function. Instead, we have to work within Unity's architecture, which loads the first scene in the scene list when the application starts. The only option available to us is to create a custom component and then link it to an object in the starting scene. Once the scene has loaded, the code in that component will start executing.

To create a component, we’ll create a class that inherits from UnityEngine.MonoBehaviour. Here's a simple example of a custom component:

using UnityEngine;

public class MyComponent : MonoBehaviour {

  private void Start() {
    // do something on component start working
  }

  private void Update() {
    // do something every frame
  }

}

Now, we can use the editor to create as many instances of this class as needed and attach them to any GameObject in the scene. Each component's Start method will be called at the beginning of its lifecycle, while Update will run every frame. Unity orders all these method calls according to its Script Lifecycle, which is a key architectural element in Unity3D. When designing how code interacts with the engine's API, developers need to understand exactly where each code fragment should run in the cycle.

This is where Unity3D starts getting quirky. Notice that Start and Update don't override any base methods; they aren't part of an interface, and aren't even public. Yet third-party code still calls them. We rarely see this approach in .NET, where such things usually rely on reflection. Unity, however, can afford to bend the language rules. Acting as a compiler, it integrates code into its event system without requiring the explicit language constructs normally used for this purpose. In other words, Unity binds methods by name, almost as if we were writing JavaScript. The methods can be private or public—it makes no difference. We can also use inheritance with virtual methods. For example, we can create components that inherit from MyComponent and override the necessary virtual methods.

Unity3D’s event system includes many other methods that Unity calls at various stages of the Script Lifecycle. We could probably call this reflection in terms of the concept, but the way it works is fundamentally different from using System.Reflection or similar runtime tools. All the magic happens at compile time, so it doesn't affect the performance of such calls.

Unity provides a class called UnityEngine.UIBehaviour, which can also be inherited from to create components. It's a MonoBehaviour subclass whose main purpose is to provide a set of empty virtual methods related to Unity UI events. However, nothing stops us from inheriting directly from MonoBehaviour and defining all the necessary methods without overriding any virtual ones. This feels a little odd, as if even the Unity developers haven't quite settled on a consistent way to best implement Script Lifecycle functions.

How to create components

We’ve already encountered one unusual aspect of C# code in Unity, and there’s more to come. As I mentioned earlier, we can add components either using the scene editor or at runtime via code. Let’s start with adding them in the editor. This part is straightforward: we select an object in the scene, click the Add Component button in the Inspector window, choose MyComponent, and Unity adds it to the object. To understand how this works, it's worth taking a look under the hood.

Each scene exists as a separate file that contains everything in that scene, including the entire object hierarchy and all its components. We create an instance of our class when we add a component. When we save the scene, Unity serializes that instance into the scene file. Once we build and run the game, Unity deserializes all our components as it loads the scene, creating new instances of their classes. If we apply the UnityEngine.SerializeField attribute to any of our fields, we can save a component with a specific value for that field. The editor even displays a UI control that enables us to edit the field on the component we've added. By default, Unity serializes public fields.

Adding components at runtime is also quite straightforward. We use the GameObject.AddComponent<T>() method for this. It's an instance method, so we first need to obtain a GameObject instance. This isn't a problem, as the Unity API provides plenty of ways to retrieve a particular GameObject. The most common approach is to use the MonoBehaviour.gameObject property.

By the way, the Unity Engine’s API naming conventions may look unusual to .NET developers: properties and fields start with a lowercase letter. Still, in almost every project I’ve seen, developers stick to the naming conventions commonly used in .NET. Here’s an example of a component that adds a copy of itself to the same GameObject three seconds after it starts executing:

using UnityEngine;

public class CopySelfComponent : MonoBehaviour {

  private float _passedTime;

  private void Update() {
    if (_passedTime > 3f) 
    {
      // gameObject is a public property of MonoBehaviour
      gameObject.AddComponent<CopySelfComponent>();
    }
    else 
    {
      // Time.deltaTime is a static property that stores the delta between
      // the start of the previous and current Update phases
      // in the Script lifecycle
      _passedTime += Time.deltaTime;
    }
  }

}

At this point, an experienced developer might ask, “What about object dependencies?” It’s no secret that OOP revolves around creating various classes and establishing clear, precise, and elegant relationships between them. In most programming languages, including C#, we use constructors to define a class’s dependencies. I’ve already described two ways to create a component, but neither involves a constructor. The reason might blow your mind: constructors for MonoBehaviour subclasses are UB in C#. For those unfamiliar with C++ and the concept of undefined behavior, here's how I'd describe it: you can use it, but it won't end well. Whatever you're trying to achieve, it'll probably fail. In other words, we can't use constructors for components.

There’s a formal alternative: the Awake() method. It's the first method Unity calls when creating a component, with a few caveats we won't get into here. However, this method doesn't take any arguments either. A common workaround for dependency injection is to define a separate method, usually called Construct(...) or Initialize(...), and pass all the required dependencies to it. Many developers will immediately recognize the downsides of this approach: we end up with an object in an inconsistent state immediately after its creation. That's something we have to live with. The usual solution is to encapsulate object creation in factories or use dedicated DI frameworks with their own APIs for creating objects and components. Here's what a typical component might look like when written using one of the most popular DI frameworks, Zenject:

using UnityEngine;
using Zenject;

public class MyComponent : MonoBehaviour {

  // Here, we can't even use `readonly` for dependencies, 
  since they change after the object is created.
  private IService1 _service1;
  private IService1 _service2;
  private IService1 _service3;

  // An attribute that tells the DI framework that this is a method 
  for dependency injection
  [Inject]
  public void Construct(
    IService1 service1,
    IService2 service2,
    IService3 service3) {
    _service1 = service1;
    _service2 = service2;
    _service3 = service3;
  }
  ...

}

Things aren’t so bad when it comes to classes that don’t inherit from MonoBehaviour. We can use them just as we would in .NET. In large projects, developers typically implement most of the application's business logic in regular classes and use components as an integration layer with the engine.

The intricacies of writing game code

Overall, I’ve covered the main differences in the language, but Unity3D development also has a few specific aspects. Remember that games are resource-intensive applications, mainly because of their graphics. However, we also need to handle code more carefully to avoid putting unnecessary strain on a device that’s already working hard. So, here are a few things to keep in mind:

Minimize calls to “expensive” APIs

The Unity library offers plenty of ways to tank an application’s performance. Almost all API calls that create or access entities are rather slow. Of course, “slow” in this context doesn’t refer to the pace perceived by a human observer; rather, it’s a measure of the speed in terms of CPU standards. Here’s an example of code that gradually changes a UI image’s color from one to another and back again:

using UnityEngine;
using UnityEngine.UI;

namespace Components
{
    public class MyBehaviour : MonoBehaviour
    {
        
        // When the scene loads, Unity prioritizes 
        the serialized field value. 
        // If the component is being created for the first time, 
        Unity uses the initialization value instead.
        [SerializeField]
        private Color _color1 = Color.red;
        
        [SerializeField]
        private Color _color2 = Color.blue;
        
        private void Update()
        {
            var img = this.GetComponent<Image>(); // THIS CODE WILL RUN SLOWLY
            
            // Some simple math is involved here. I'll spare you the details.
            // You can look into it on your own if you're interested.
            img.color = Color.Lerp(_color1, _color2,
            Mathf.PingPong(Time.time, 1f));
        }
    }
}

If the code accumulates enough of such calls, they’ll significantly impact performance. A better approach is to cache Image in Awake() or declare it as a serialized field so we can assign its value in the editor. We can drag and drop many types derived from UnityEngine.Object into UI fields in the editor to assign references to specific instances like this:

using UnityEngine;
using UnityEngine.UI;

public class MyBehaviour : MonoBehaviour
{
    [SerializeField]
    private Color _color1 = Color.red;
    [SerializeField]
    private Color _color2 = Color.blue;
  
    private Image _image;

    private void  Awake()
    {
        _image = GetComponent<Image>();
    }
        
    private void Update()
    {
        _image.color = Color.Lerp(_color1, _color2, 
        Mathf.PingPong(Time.time, 1f));
    }
}

Or like this:

using UnityEngine;
using UnityEngine.UI;

public class MyComponent : MonoBehaviour
{
  
  [SerializeField]
  private Color _color1 = Color.red;
  [SerializeField]
  private Color _color2 = Color.blue;

  [SerializeField]
  private Image _image;
        
  private void Update()
  {
    _image.color = Color.Lerp(_color1, _color2, 
    Mathf.PingPong(Time.time, 1f));
  }
}

Here are some other commonly used — though not the only — methods that can cause performance issues:

• GetComponent<T>()
• GetComponents<T>()
• GetComponentInChildren<T>()
• GetComponentInParent<T>()
• FindObjectOfType<T>()
• FindObjectsOfType<T>()
• Find(string)
• FindWithTag(string)
• FindGameObjectsWithTag(string)

How to create objects

Object creation is another aspect of Unity development that deserves careful attention. I’m referring to both Unity3D objects (GameObject and MonoBehaviour) and regular class instances. In short, the best approach for performance is to avoid creating objects altogether. This is why Unity3D developers extensively use object pooling. It's hardly a groundbreaking idea, and Unity3D already provides a built-in class for this purpose: UnityEngine.Pool.ObjectPool<T>. Why does this matter in the game development industry? There are different reasons for Unity3D objects and regular class instances.

For regular class instances, the issue is straightforward: memory allocation. One of the biggest threats to application performance is the garbage collector. Just as in .NET, the garbage collector pauses code execution to manage memory. Creating large numbers of short-lived objects can trigger frequent garbage collection, causing FPS drops during those pauses. Developers may encounter this issue when their code creates various collections to process and transfer data, DTOs, and similar objects.

Although they usually have a longer lifespan, memory allocation for GameObject instances and components is another concern. The issue once again lies with the slow API responsible for creating them. Sometimes, we need to transition from one game state to another while displaying large numbers of objects along the way. For example, we might load an environment, spawn a large number of units, or create bullets when firing a weapon, which is a now-classic use case. Our goal in these situations is to create game objects as quickly as possible to prevent FPS drops and loading screens that frustrate players. That's where object pooling comes in, ideally with the warm pool. However, we shouldn't forget about the balance between memory usage and performance. Pooling too many objects will cause the application to use too much memory, creating its own set of problems. So, we should make smart use of the device's available resources.

Structs

For the same performance reasons, it’s a useful skill for any developer to know when to use a struct instead of a class, as this helps reduce the load on the garbage collector. I won’t go into much detail here, since the rules are roughly the same as in .NET. It’s also important to remember about boxing and avoid unnecessarily allocating structs on the heap.

How to destroy objects

When it comes to destroying objects, Unity has a small peculiarity. Regular classes depend on the garbage collector. However, things become more complicated when it comes to objects that are part of the engine. Let’s take GameObject, for example. When we write new GameObject(), we create a new instance of the GameObject class. At the same time, Unity adds the object to the hierarchy of the currently open scene. It may seem obvious that if the code no longer contains any references to this instance, it will still be part of the scene and will not be removed by the garbage collector.

To explicitly remove the object from the scene, we need to call the UnityEngine.Object.Destroy(UnityEngine.Object) static method and pass the instance as an argument. This may seem obvious for GameObject and MonoBehaviour subclasses. We know these objects are part of the scene, so it makes sense that we need to take explicit action to remove them. However, there are less obvious cases, too.

For example, the Texture2D class is an abstraction of a texture, which is an image. We can create a Texture2D instance and assume that we're the only ones holding a reference to it, so once we lose all references, the garbage collector will remove it. Unfortunately, that's not how it works. The rule is simple: we should call UnityEngine.Object.Destroy(UnityEngine.Object) for all explicitly created subclasses of UnityEngine.Object. The reason is that C# objects in the Unity API are simply wrappers for native objects belonging to the engine's C++ code. If we lose all references to our object, only the C# wrapper is removed. However, the C++ object under the hood still occupies memory. On the other hand, calling UnityEngine.Object.Destroy(UnityEngine.Object) destroys only the C++ object. So, after calling UnityEngine.Object.Destroy(UnityEngine.Object), we still have the same C# object, but all of its methods will throw errors because the object that handles the logic has been destroyed.

We need to be careful when comparing UnityEngine.Object subclasses to null. Unity overrides the equality operator for UnityEngine.Object. So, in addition to checking whether both operands are null, Unity also checks whether the C++ object has been destroyed. If it has, comparing the object to null will return true. This behavior can be confusing and makes comparisons to null relatively expensive. So, it's better to avoid them in frequently executed code as well.

Linq

LINQ extension methods are incredibly convenient. They’re also highly effective in middleware-based architectures, where different layers of an application can process the same enumerable object in sequence without repeatedly iterating over its elements. However, there’s one major drawback to using LINQ with Unity3D: its extension methods return objects that require heap allocations.

This brings us back to the issue of unnecessary object creation we discussed earlier. The overhead is negligible on its own, but constantly using it in frequently executed code can create a problem. I recommend keep using LINQ if you follow the middleware-based approach. However, try to replace LINQ methods with regular for and foreach if you're using them within a single method.

Also, be careful with methods that execute LINQ queries, such as ToList(), ToArray(), and so on, as they can significantly increase memory usage. Call them only when you actually need the query result as a concrete collection, or avoid them altogether. That said, I don't think things are any different here compared to .NET.

Concurrency and asynchronous programming

Concurrency in Unity3D can be tricky. As I mentioned earlier, code dispatched to another thread simply won’t run at all on WebGL. I haven’t encountered any concurrency issues with how threads behave at the OS level on other platforms. However, almost every Unity API call will throw errors if we try to make it from a thread other than the main one. Experienced Unity developers might point to the Job System, but as far as I know, it only provides limited access to Transform.

On the one hand, this is nice. We don’t have to struggle too much with synchronization, and neither do Unity3D developers. Many Unity developers don’t even know about the lock keyword, which is considered one of the cornerstones of concurrency in C#. On the other hand, we may sometimes want to use multiple CPU cores to modify the properties of a large number of Unity objects.

Still, Unity makes extensive use of concurrency under the hood, and its API provides asynchronous operations for loading data from disk, handling network communication, and performing some other resource-intensive tasks. That said, developers at Unity Technologies aren’t particularly fond of the async/await syntax, so we often have to make do with callbacks and events. Of course, nothing stops us from wrapping these in a proper async API using TaskCompletionSource and a few other methods.

Unity also offers a rather unconventional approach to asynchronous programming called coroutines. Basically, coroutines enable developers to pass an enumeration to the Unity3D engine via its API. Each element tells the engine when to retrieve the next one. When combined with the yield operator, this works as a makeshift version of async/await. It looks something like this:

public IEnumerator Coroutine() {
  Debug.Log("Do something");
  
  yield return new WaitForNextFrame();
  
  Debug.Log("Do something in the next frame")
    
  yield return new WaitForSeconds(2f);
  
  Debug.Log("Do something after two seconds");
  var t = Task.Delay(4000);
  
  yield return new WaitUntil(() => t.Completed);
  
  Debug.Log("Do something after 4 more seconds.");
}

...

someMonoBehaviourInstance.StartCoroutine(Coroutine());

...

You may have noticed that starting a coroutine requires calling a method on a specific object instance. This tight coupling to an object is one of the advantages of coroutines: Unity cancels a coroutine when we destroy its associated object using UnityEngine.Object.Destroy(obj). In every other respect, though, coroutines are simply a less convenient alternative to async/await.

Unity3D also has its share of issues with Task. Firstly, it runs on the thread pool, so we run into the same problem: we can't use the Unity API from those threads. Secondly, Unity3D developers try to avoid allocating memory on the heap, and Task is a class that allocates memory on the heap. ValueTask helps reduce this overhead, as does UniTask, its Unity-specific counterpart. UniTask is an open-source plugin that offers an alternative to ValueTask. It provides additional optimizations and enhances the user experience when working with the Unity API. The library also includes various extension methods for Unity classes, providing convenient ways to use them with await.

Unity3D also has its own implementation of SynchronizationContext. It slightly streamlines the use of Task and ensures that the code after await won't run on a different thread. If the object we're await-ing executes on Unity's main thread, the code after await will run as soon as the execution finishes. If we use concurrency instead, the code after await will run during an early stage in the Script Lifecycle. WPF uses a similar synchronization context.

Covering code with automated tests

Unity includes a built-in editor window for running and viewing tests. The test framework is based on NUnit, but there are a few differences. First, Unity supports two types of automated tests: PlayMode and EditMode, which are just regular NUnit tests. We can create usual C# objects, mock dependencies using a mocking library such as NSubstitute (also available through OpenUPM), perform various operations, and check the results. PlayMode tests, on the other hand, run the Script Lifecycle. They enable us to check how the MonoBehaviour subclasses behave over time, how they respond to various physics triggers in the Script Lifecycle, and so on.

In my experience, relatively few projects have made extensive use of PlayMode tests. Most teams move as much business logic as possible into standard C# classes. This leaves the MonoBehaviour subclasses as a thin layer between the C# architecture and the Unity API. I think the main reason is that testing anything related to the Script Lifecycle can be challenging. The engine's physics and execution systems don't provide APIs that offer the level of fine-tuning often required when writing automated tests.

One disadvantage of testing in Unity is the lack of support for asynchronous tests. This is where the coroutines mentioned above come in, replacing asynchronous operations. It looks something like this:

[UnityTest] // This is a special attribute for such tests
public IEnumerator AsyncTest() {
  // Arrange
  SomeService someSerivce = // create some service with mocked dependencies

  // Act
  Task<bool> asyncHandle = someService.SomeAsyncMethod();
  yield return new WaitUntil(() => asyncHandle.IsCompleted);

  // Arrange
  Assert(true, asyncHandle.Result);
}

Conclusion

Those were the main points to keep in mind when starting to write C# code in Unity3D. If you have any comments or notice any errors, please leave a comment on the article or open an Issue on GitHub.

Want to learn more?

The PVS-Studio team loves to publish valuable content for C# developers and folks working in game development. Subscribe to our newsletter to follow the articles from the PVS-Studio website.

Here are some articles:

• I found some bugs in Create mod and checked them in Minecraft
• Game++. Part 2.2: Types of optimization
• What’s new in C# 15: Overview

Unity3D for .NET Developers: How to get started was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Static Analysis for Better Code

PVS-Studio is a Static Application Security Testing (SAST) tool that detects issues in source code, from simple typos to potential vulnerabilities. It offers over 1,300 diagnostic rules for C, C++, C#, Java, JavaScript, TypeScript, and Go, including specialized rules for particular technologies and support for standards such as MISRA and AUTOSAR.

Watch the video to learn more:

• what languages and standards the analyzer supports;
• how it works;
• where it fits into your development workflow;
• and the kinds of bugs it can catch.

Visit our website to get a free 30-day trial!

What Is PVS-Studio? was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

How did I end up here, and why did I even decide to cover this topic?

For quite some time, I’ve been working on supporting the MISRA C++ 2023 rules. Yes, PVS-Studio analyzer learns how to check whether a codebase complies with this standard. My task was to implement support for a rule that regulates the co-use of enumerations and bit fields. It all looked simple in my head: all I had to do was check whether the enum values with a fixed fundamental data type fit within the specified bit field width.

Have you ever started a task that seemed like a fun little adventure that would take just a couple of hours, only to find yourself stuck in a bottomless pit of troubleshooting for an entire week? That’s exactly what happened to me. I got bogged down in trying to implement support for this rule.

As I tried to untangle the mess, I realized one thing: bit fields in C++ are an underrated topic that every C++ developer should know about.

The basics: what are bit fields?

In C++, a bit field is a data-packing mechanism that allows you to allocate memory within a structure or class bit by bit instead of byte by byte. Unlike ordinary types, which always occupy at least one byte, bit fields enable you to allocate exactly the number of bits you want to a particular variable. This makes them invaluable when memory is strictly limited or when you need to store a set of flags as compactly as possible.

Let’s take a look at the syntax for declaring bit fields. It may differ slightly depending on your technical requirements, but the fundamental structure is as follows:

type-specifier declarator : constant-expression ;

Here, constant-expression specifies how many bits to allocate to a particular field.

The syntax for bit fields is quite interesting. We use a colon to give the compiler a direct instruction to override the usual memory allocation rules. In standard C++ code, the smallest addressable unit is a byte, which contains CHAR_BIT bits. The implementation defines the CHAR_BIT macro, but its most common value is eight. The colon separates the variable's logical name from its actual size. This forces the compiler to divide memory into small chunks of a specific size.

This approach saves memory. How? It eliminates empty and redundant bits. When you declare standard variables, the processor rounds their size up to whole bytes due to architectural constraints. Bit fields work around this limitation by packing multiple fields into a shared storage unit.

To understand how bit fields save space, we’ll compare two ways of storing the same data. Let’s say we need to record three system parameters:

• activity status (on/off): 1 bit is enough (values 0 or 1);
• mode (4 modes): 2 bits are enough (combinations 00, 01, 10, and 11);
• error code (from 0 to 7): 3 bits are enough (combinations from 000 to 111).

All the essential information about the object state takes up exactly six bits.

Option 1. Standard structure

If we create a standard structure in C++, the compiler allocates one byte of memory for each type, since this is the minimum addressable size:

struct StandardStruct 
{
  bool is_active;   
  char mode;        
  char error_code; 
};

The full code:

The example:

#include <iostream>

struct StandardStruct 
{
  bool is_active;   
  char mode;        
  char error_code; 
}; 

int main()
{
  StandardStruct stStruct;
  std::cout << "Sizeof stStruct: " << sizeof(stStruct)
            << "byte(s)" << std::endl;
}

Program output:

Sizeof stStruct: 3 byte(s)

The program uses 24 memory bits. 24 memory cells were allocated for our six units of information; the remaining 18 cells simply remain empty because the processor architecture can’t directly handle units smaller than one byte.

Option 2. Structure using bit fields

Now let’s add the colon syntax. The compiler starts with a fundamental data type, or container, such as unsigned char, which is one byte (eight bits) in size. It then begins packing fields tightly inside the container:

struct BitFieldStruct
{
  unsigned char is_active  : 1; 
  unsigned char mode       : 2; 
  unsigned char error_code : 3; 
};

The full code:

The example:

#include <iostream>

struct BitFieldStruct
{
  unsigned char is_active  : 1; 
  unsigned char mode       : 2; 
  unsigned char error_code : 3; 
};

int main()
{
  BitFieldStruct stStruct;
  std::cout << "Sizeof stStruct: " << sizeof(stStruct)
            << " byte(s)" << std::endl;
}

Program output:

Sizeof stStruct: 1 byte(s)

As a result of this mechanism, the entire structure is compressed to one byte. In memory, it appears as a single eight-bit array divided into sectors:

The compiler handles everything: when reading from or writing to the mode variable, it automatically generates hidden bit shifts and masks to isolate the required two bits from the rest of the data. This high-density packaging significantly reduces RAM usage in large arrays and embedded systems (microcontrollers).

How bit fields work and their limitations

We’ve covered the basic principles and syntax of bit fields. Now let’s take a closer look at how they work and explore the rules imposed by the language.

Bit fields can exist only inside structures or classes. Developers can’t declare a bit field as a standalone variable inside a function. It’s also impossible to apply the const or volatile qualifiers directly to an individual bit field. Instead, you can apply them indirectly by declaring an object of that structure or class with the relevant qualifier.

Data types for bit fields

The next thing to discuss is which data types you can use with bit fields. The C++ standard allows this mechanism only for integral types and enumerations. Trying to limit the bit width of floating-point types (float, double) or complex objects such as std::string is technically impossible and will result in a compilation error.

Bit fields support the following types:

1. Integral types (char, wchar_t, char8_t, char16_t, char32_t, bool, short, int, long, and long long).

These are the standard options for creating masks and flags. Before C++14, explicitly specifying the signed or unsigned modifier for an int bit field was critical. Otherwise, the compiler determined how to interpret the signed bit. For example, a one-bit int field without an explicit unsigned modifier could take 0 and -1 instead of the expected 0 and 1. For a bool field, allocating exactly one bit is enough.

2. Enumerations (enum and enum class).

Bit fields work well for storing enum types with a small set of possible values. If an enum has four possible states, allocating two bits is enough.

3. std::byte (C++20).

Starting with C++20, std::byte officially joined the list of permitted types. If a structure handles raw data at the hardware level, using std::byte clearly communicates the developer's intent and prevents accidental arithmetic errors.

Rules for working with bit fields

The third important topic to cover is the rules governing bit fields. In C++, four key restrictions apply. Developers cannot:

• declare an array of bit fields;
• take the address of a bit field;
• create a pointer to a bit field;
• create a reference to a bit field.

Let’s look at some examples to understand why bit fields follow these rules and what happens when you try to get around them. We’ll start with a simple structure:

struct HardwareFlags
{
  unsigned int mode   : 3;
  unsigned int status : 1;
};

No taking addresses or creating pointers

The rule against taking addresses or creating pointers stems from a fundamental aspect of computer architecture: a bit field has no physical memory address. Modern processor architectures use the byte as the smallest addressable unit of memory (CHAR_BIT bits). A processor simply has no way to address, say, the third bit within a byte.

For this reason, we can’t use the address-of operator & on a bit field:

HardwareFlags flags;
auto address = &flags.mode;
int* ptr = &flags.mode;     // doesn't compile

Since individual bit segments don’t have unique addresses in a memory cell, it’s physically impossible to obtain a direct pointer to such a variable.

No address, no references

There’s another restriction that comes from the inability to take a bit field’s address: you can’t bind a standard reference & to a bit field. In C++, references rely on pointers and memory addressing. Without an address, there's simply nothing for a reference to bind to:

HardwareFlags flags;
void checkMode(const unsigned int& m);

unsigned int& ref = flags.mode;        // doesn't compile
checkMode(flags.mode);                 // doesn't compile

Arrays: why pointer arithmetic falls short

I’m afraid I have some bad news: you can’t create an array of bit fields either. The reason lies in pointer arithmetic. When you create an array, the compiler guarantees that its elements occupy consecutive memory locations. When you access the i-th element using arr[i], the compiler calculates its address relative to the start of the array via pointer arithmetic.

struct BrokenStruct
{
  unsigned int items[5] : 2; // doesn't compile
};

The anatomy of alignment

Although bit fields aim to save memory, C++ doesn’t specify their exact layout within a structure. Compiler developers have considerable freedom in how they pack bits, so a structure’s actual size depends on the target platform. This flexibility is impressive, but to understand why it exists, let’s take a look at what the standard says:

Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit.

Note. Bit-fields straddle allocation units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others.

In reality, this means that the layout rules come not from the language, but from the Application Binary Interface (ABI) defined for a particular OS. For example, many Unix-like systems use the Itanium ABI, but it also leaves some aspects of bit ordering unspecified. The packing rules can vary depending on the OS and architecture. For example, MSVC on Windows and GCC on Linux may compile the same structure differently.

In this section, we’ll focus specifically on how bit fields work. I’ll touch on alignment briefly, as I’ve already covered it in a series of articles: the first part introduces the basic principles, while the second and third explore how inheritance and virtual functions affect alignment.

How compilers divide memory into allocation units

The phrase “Bit fields are packed into some addressable allocation unit” describes the concept of an allocation unit. According to the C++ standard, an allocation unit is an addressable block of hardware memory, such as a byte or machine word, into which bit-fields are packed consecutively. The exact behavior of these units is implementation-defined and depends largely on the platform’s ABI.

A compiler never allocates memory for individual bits out of thin air. Instead, it starts with the fundamental data type you specify when declaring a field and uses it to determine the size of the physical container. For example, if you use unsigned char, the allocation unit is one byte (8 bits). If you choose unsigned int, it occupies four bytes (32 bits). The compiler takes this entire physical container and starts slicing it into the specified logical segments, one bit at a time, until no space remains. Once the container runs out of room, the compiler allocates a new unit for the next fields.

Let’s look at how a compiler packs data:

The packing algorithm

• The compiler receives a list of bit fields declared in a structure.
• It allocates the first container (memory allocation unit) based on the size of the fundamental data type.
• The first bit field occupies the beginning of the newly allocated container.
• The compiler calculates how many free bits remain in the current container.
• It takes the next bit field from the list for analysis.
• It compares the field’s width in bits with the number of free bits remaining.
• If the field fully fits in the remaining space, the compiler places it in the current container, directly next to the previous one.
• After successfully placing the field, the compiler updates the free-bit counter and moves on to the next field.
• If the field’s width exceeds the available space, the compiler must resolve a standard ambiguity.
• The compiler consults the ABI rules for the target architecture. On x86 and ARM, the compiler moves the entire field to a new container to preserve CPU performance. On other architectures, such as some RISC processors, it may split the field into two parts to maximize memory saving, filling the remaining space in the current container.
• The compiler closes the current container, leaving any unused bits empty.
• It opens a new, empty container (allocation unit).
• The field that didn’t fit occupies the beginning of the new container.
• The compiler then recalculates the number of free bits in the new container and repeats these checks for the remaining fields.
• The process is complete once the compiler has assigned all bit fields in the list to their respective containers.

Note. The direction in which the compiler fills a container depends on the ABI rules for the target architecture. The order can be from least to most significant bit or vice versa.

sizeof bloat: good vs. bad alignment

Why are we even going into such detail about the compiler’s step-by-step algorithm? Bit fields can become a ticking time bomb if one doesn’t understand these inner workings. You write code expecting to save memory, but end up with a structure that’s several times larger than normal. Declaring bit fields haphazardly can trigger sizeof bloat. The compiler loses its capability to pack data tightly and starts inserting unused bytes.

Two classic developer mistakes usually lead to such hidden memory leaks:

• Creating giant fields whose widths exceed the physical capacity of the current memory container.
• Mixing data types indiscriminately, so adjacent fields keep switching between fundamental data types (for example, char, then int, and then char again). This is a critical issue on Windows (Microsoft ABI), where the compiler starts a new allocation unit whenever the type changes, leaving unused padding behind. This limitation doesn't affect GCC and Clang on Linux and macOS: they ignore changes in base types and continuously pack fields, minimizing alignment padding.

To see just how much of a difference this makes, let’s compare two scenarios: one that shows how not to do it, and one that shows how to do it right.

Example N1. Inefficient layout (poor alignment)

Imagine a structure where we’ve tried to save memory by mixing different types. For this example, let’s use MSVC on Windows:

struct BadPacking
{
  unsigned char a : 4;
  unsigned int b  : 3;
  unsigned char c : 4;
};

The structure fields will be arranged as follows:

The constant switching between types (char > int > char) completely disrupts continuous packing. MSVC treats each type change as a command to close the current allocation unit. It stops filling the byte after a, leaves the remaining bits as padding, and aligns the address for the next block. It then opens a 4-byte container for the int b field, which takes three bits, and immediately closes it to open a container for the char type. As a result, large gaps of unused memory remain. The compiler also has to follow alignment rules, so it performs final alignment on the entire structure. Then, sizeof(BadPacking) returns 12 bytes. Clang and GCC, on the other hand, can handle this structure efficiently: they know how to pack these fields as tightly as possible.

Example N2. Optimized layout (good alignment)

To fix this, simply follow the golden rule: convert all fields to a single base type and group them by meaning.

struct GoodPacking {
    unsigned int b : 3; 
    unsigned int a : 4;  
    unsigned int c : 4;  
};

Let’s take a look at how the elements are arranged in the structure now:

The compiler now works with uniform and predictable four-byte blocks. The b field occupies almost the entire first block, while the a and c fields require only eight bits combined, fitting perfectly into the second int block. As a result, sizeof(GoodPacking) returns just eight bytes (exactly two int containers). The data is packed as tightly as possible so the processor can access it without any unnecessary overhead. This gives us a compact structure.

Hardware padding: reserving space for unused bits

When writing drivers, implementing network protocols, or working with processor registers, you may encounter hardware controllers with gaps in their bit layout. For example, a chip manufacturer may reserve certain bits in a hardware byte for future use, meaning you can’t write or read data to or from them.

To precisely mirror the register’s physical layout in code, you can use unnamed bit fields with non-zero widths as placeholders or padding:

struct TestController
{
  unsigned char transmit_ready : 1; 
  unsigned char                : 3; 
  unsigned char receive_ready  : 1;
  unsigned char                : 3; 
};

However, they still occupy their designated space in memory when the compiler generates the structure. This enables you to map a C++ structure to the microcontroller’s physical memory layout with bit-level precision, without shifting any of the meaningful flags.

Forcing a packing boundary: why use a zero-width bit field?

In some cases, such as when working with hardware interfaces, it’s necessary to prevent the compiler from packing fields into the current allocation unit. For example, you may need to ensure that the next data block starts at a new byte or machine word. To do this, you can use an unnamed zero-width bit field:

struct Test
{
  unsigned char command : 4; 
  unsigned char         : 0; 
  unsigned char data    : 4; 
};

A zero-width bit field acts as an artificial boundary. It tells the compiler that the current memory allocation unit is closed. The next field must start in a new allocation unit and can’t use any remaining bits, even if plenty of space remains. One important rule to remember when working with these fields is that you can’t give a zero-width bit field a name. It must always remain unnamed.

Under the hood: how compilers store bit fields

Now, it’s time to take a look under the hood. The internal structure of bit fields in C++ is subject to implementation-defined behavior. The C++ standard abstracts away the physical details, providing only high-level rules and delegating the challenging tasks to the compiler and ABI. To understand how data actually occupies memory, we need to take a closer look at three fundamental factors: bit allocation order, compiler differences across architectures, and binary portability.

Bit allocation order

The first and most important factor that determines a structure’s physical layout in memory is the order in which the compiler places bits inside an allocated container. Most developers are familiar with byte order, which determines how multibyte values are mapped to memory addresses. A similar concept exists at a lower level, though: the compiler decides which direction to fill individual bits within a particular byte or machine word. The C++ standard deliberately leaves this detail unspecified, so each compiler’s implementation determines how it fills each container. In real world, compilers use one of two opposite approaches: packing from the least significant bit to the most significant bit (LSB-first, Little Endian) or from the most significant bit to the least significant bit (MSB-first, Big Endian).

In the LSB-first scheme, the compiler fills the allocated container from right to left. In other words, packing begins with the least significant bit, or bit 0. The first bit field declared in the structure occupies the rightmost bits, and each subsequent field sits directly next to it, extending leftward toward bits with greater binary significance. GCC, Clang, and MSVC all use this approach when compiling code for architectures such as x86, x86–64, and ARM.

The opposite strategy is MSB-first (Most Significant Bit-first). In this case, the compiler packs bits from left to right, starting with the highest available bit: for example, the seventh bit in a one-byte container. The first field in the structure occupies the most significant bits on the left side of the container, while subsequent fields follow in sequence toward the least significant bits. This is common in compilers for network processors.

Let’s see how this works in real code. Take a look at the following structure:

struct HeaderFlags
{
  uint8_t version : 3; 
  uint8_t type    : 2; 
  uint8_t id      : 3; 
};

The full code:

#include <cstdint>
#include <cstring>
#include <iostream>

struct HeaderFlags
{
  uint8_t version : 3; 
  uint8_t type    : 2; 
  uint8_t id      : 3; 
};

uint8_t result_byte = 0;

int main()
{
  HeaderFlags flags;
  flags.version = 1;
  flags.type = 2;
  flags.id = 4;

  std::memcpy(&result_byte, &flags, sizeof(HeaderFlags));
    
  return 0;
}

We created a HeaderFlags structure that occupies exactly one byte and assigned three values to its fields. To safely extract the packed byte without violating memory access rules, we used std::memcpy and copied the result into the result_byte global variable.

Now let’s see how different compilers handle this code. To avoid wading through unnecessary assembly instructions, we’ll enable the -O2 optimization level.

The GCC x86–64 output:

.globl std::ios_base_library_init()
"main":
        mov     BYTE PTR "result_byte"[rip], -111 ; <=
        xor     eax, eax
        ret
"result_byte":
        .zero   1

The mov instruction contains the -111 negative value, which is how x86-64 assembly represents one-byte constants. Converting it to the familiar unsigned format gives us 256 - 111 = 145, which is 0x89 in hexadecimal or 0b1001'0001 in binary. The compiler has eliminated all the intermediate packing instructions and written the final result directly to memory. Since the target cell occupies four bytes, the 0x00000089 value appears in memory as the 89 00 00 00 byte sequence. The fact that the least significant byte 89 appears at the lowest memory address confirms the LSB-first (Little Endian) layout.

Switching the compiler to the Big-Endian MIPS architecture, such as mips-linux-gcc 16.1.0, reveals a completely different picture. The assembly output for this platform looks as follows:

.globl std::ios_base_library_init()
main:
        lui     $2,%hi(result_byte)
        li      $3,52                 # 0x34
        sb      $3,%lo(result_byte)($2)
        jr      $31
        move    $2,$0

result_byte:
        .space  1

Here, the li $3, 52 instruction loads the precomputed constant 52, which is 0x34 in hexadecimal and 0b0011'0100 in binary. The compiler uses the MSB-first strategy, packing bits from left to right: the version field occupies the most significant bits 7–5, type occupies bits 4–3, and id lands in the least significant bits 2–0. We can illustrate the bit layout schematically as follows:

This example shows how changing the bit endianness can completely change the physical representation of data. Directly transferring raw bytes between systems that use different bit-packing schemes can corrupt the data structure. Understanding this mechanism leads us to the second key factor: the architectural differences between compilers and the role of the ABI.

Platform dependence: the anatomy of the MSVC vs. GCC/Clang conflict

We often think that fundamental data types in C++ behave deterministically on the same hardware architecture. However, bit fields have an important caveat: the compiler decides how to arrange them in memory. The in-memory layout of the same structure compiled for an x86–64 processor can differ significantly between Windows and Linux. The physical layout of bit fields follows the rules defined by the ABI. The ABI specifies how the operating system’s platform expects the compiler to group, align, and divide data into individual fields.

Several ABI standards define different approaches to data packing. Here are some of the most widely used ones:

• System V ABI (based on the Itanium C++ ABI) is used by default in GCC and Clang on Linux, macOS, and FreeBSD. Although developers originally designed this standard for Intel Itanium processors, it has become a common foundation for GCC and Clang across various architectures, including x86, x64, and ARM64.
• RISC-V ABI is a specification for the RISC-V open-standard architecture. This standard isn’t formally derived from the System V ABI, but it shares many similar data packing and alignment rules. The goal is to pack bit fields in memory as tightly as possible.
• Microsoft x64 ABI is used by default in MSVC on Windows systems running on the x86–64 architecture.
• Microsoft ARM64 ABI is the modern Windows standard for ARM64 processors. It’s designed with x64 limitations in mind. Its structure alignment rules offer greater flexibility, and its calling convention enables programs to pass data directly through registers, reducing stack usage.

These documents differ in a single rule.

The rule. Compatibility between different data types

Developers can declare consecutive bit fields with different fundamental data types within the same structure. This kind of type mixing is one of the main causes of hidden memory bloat, as compilers use very different algorithms to handle boundaries between allocation units with different fundamental types.

Let’s see what happens when these rules conflict. We’ll run an experiment using Compiler Explorer and measure the structure’s size with the sizeof operator. Let's write the following structure:

struct PackagingConflict
{
  uint8_t  mode : 4; 
  uint32_t type : 4; 
};

The full code:

#include <iostream>
#include <cstdint>

struct PackagingConflict {
    uint8_t  mode : 4; 
    uint32_t type : 4; 
};

int main() {
    std::cout << "--- BITFIELD PACKING SIZES ---" << std::endl;
    std::cout << "1. PackagingConflict size: " << sizeof(PackagingConflict)
              << " byte(s)" << std::endl;    
    return 0;
}

Look at the outputs from Clang and MSVC:

The Clang program output:

--- BITFIELD PACKING SIZES ---
1. PackagingConflict size: 4 byte(s)

The MSVC program output:

--- BITFIELD PACKING SIZES ---
1. PackagingConflict size: 8 byte(s)

Here’s a visual layout of the memory components:

Upon analyzing this structure, we can spot a clear difference: Clang packs it into four bytes, while MSVC inflates it to eight. Since the fields use different fundamental data types (uint8_t and uint32_t), both compilers initially keep them separate. They allocate one byte for the mode and add three bytes of padding so the type starts at a properly aligned four-byte boundary. Clang then applies an Itanium ABI optimization, trimming the unused part of the second allocation unit to save space. MSVC, on the other hand, strictly follows the Microsoft ABI rule that the structure's total size must be a multiple of its largest fundamental type (uint32_t, or four bytes). It preserves the full four-byte allocation unit for each block, doubling the structure's final size.

The real danger is when we move between platforms with different ABIs, the well-defined physical boundaries of data in memory simply disappear. Hidden padding and differences in how compilers handle unused space within allocation units can completely change the internal field layout. This makes bit fields unsuitable for direct byte-by-byte copying, file storage, or binary serialization. If a structure is saved using Clang’s four-byte layout and then read using MSVC’s eight-byte layout, the program reads from incorrect offsets, resulting in corrupted data.

Binary fragility and industry standards

Due to inconsistencies in alignment and bit ordering, structures containing bit fields offer virtually no binary portability. C++ compilers treat bit fields as a black box: you write concise code, but leave the actual memory layout to chance.

Using bit fields is virtually guaranteed to cause problems in three areas:

1. Network I/O. Sending a structure directly over a socket with a call like send(sock, &packet, sizeof(packet), 0) is a ticking time bomb. If the server runs Linux (Clang) and the client runs Windows (MSVC), ABI differences can shift bit positions, turning valid flags into a meaningless jumble.

2. File I/O (serialization). For example, writing bit fields directly to a file byte by byte with fwrite ties the data to a specific ABI. According to Section 6.7.2.1 of the ISO C standard, the order in which compilers lay out bit fields and padding is implementation-defined behavior. Writing such a structure to a file on Linux and then reading it on Windows can cause differences between the Microsoft and System V ABIs to result in the program reading corrupted data from incorrect offsets.

The C++ object model in C++23 partially addresses the issue of object lifetimes with the std::start_lifetime_as function. However, this function only validates the creation of an object from raw bytes in memory; it doesn't address differences in the physical layout of fields across platforms. Moreover, copying uninitialized structure padding when writing data to a file technically involves reading indeterminate values, which leads to undefined behavior.

3. Drivers and hardware (Hardware MMIO). A microcontroller’s hardware defines the bit layout of its registers, and it never changes. In C, however, the order and alignment of bit fields, as well as the width of memory accesses, depend on the implementation. So, describing a hardware register with bit fields doesn’t guarantee that each field will map to the intended bits. Switching compilers, compiler versions, or build flags can shift the fields, causing writes to affect the wrong register bits.

Developers avoid bit fields entirely for any task that requires a strictly defined data layout, such as network communication, file storage, or hardware registers. Instead, they use fixed-width integer types (uint8_t, uint16_t, and uint32_t) combined with explicit bit shifts (<<, >>) and bit masks (&, |).

Differences between compiler ABIs make it difficult to use standard bit fields without manual alignment for cross-platform data exchange. A program compiled on Linux using GCC or Clang produces a data structure that a Windows application built with MSVC can’t read correctly because the Windows application expects alignment and padding bits in different locations.

Use cases: where bit fields actually make sense

In C++ development, bit fields serve specific engineering needs rather than abstract memory-saving goals. There are two main scenarios where this feature proves most useful.

1. Compact metadata for millions of objects. Developers often need to store metadata, such as status flags, type IDs, and reference counts, for huge numbers of small elements when designing game engines, custom memory allocators, or databases. Allocating a separate variable for each flag can waste enormous amounts of memory due to compiler-imposed alignment. Bit fields let you pack several independent properties into a single byte, minimizing memory usage.

2. Optimizing CPU cache usage (Cache Lines). Modern processors don’t read data from RAM one item at a time. Instead, they fetch large blocks of data called cache lines, typically 64 bytes each. When a data structure becomes too large, each cache line contains fewer useful objects. This forces the processor to repeatedly wait for slow RAM access, resulting in a cache miss. Using bit fields to pack data tightly allows the CPU cache to hold several times more objects. An algorithm can run several times faster when it iterates over objects sequentially in large batches because it retrieves data from the CPU’s ultra-fast cache.

Modern alternatives to bit fields

Due to portability issues, dependence on platforms, and restrictions on address taking, developers often need to look for alternatives to traditional bit fields. Modern C++ offers three main architectural alternatives, each designed to address a specific use case.

The classic approach: manual bit masks and shifts

If you need to have complete control over the physical position of each bit, the classic C-style approach is your best option. Rather than relying on the compiler to automatically pack bits, you select a fixed-width integer type and manually manipulate individual bits using bitwise operators (&, |, ~, ^, <<, and >>).

Take a look at the example:

class DeviceConfig
{
public:
  void set_mode(uint8_t mode)
  {
    data = (data & ~MODE_MASK) | ((mode << 1) & MODE_MASK);
  }

  uint8_t get_mode() const
  {
    return (data & MODE_MASK) >> 1;
  }

private:
  static constexpr uint8_t ENABLE_CLOCK_MASK = 0x01;
  static constexpr uint8_t MODE_MASK         = 0x0E;
  static constexpr uint8_t INTERRUPT_MASK    = 0xF0;

private:
  uint8_t data = 0;
};

Yes, this code is more complex, but its binary layout is now completely independent of the compiler and ABI. This makes it an ideal approach for implementing network protocols and writing device drivers. The only thing developers need to keep in mind is the processor’s byte order, or endianness. Multi-byte values appear in reverse order on Big Endian architectures compared to Little Endian ones.

For maximum safety: the std::bitset container

The built-in std::bitset class is the best choice if code safety and convenient manipulation of Boolean flags matter more than saving memory in individual structures.

This container provides a fixed-size array of bits whose size is specified as a template parameter at compile time. It encapsulates all bitwise operations, providing developers with a high-level, type-safe interface.

Look at the following example:

#include <bitset>
#include <iostream>

enum Permission
{
  Read = 0,
  Write = 1,
  Execute = 2,
  Admin = 3,
  MaxPermissions 
};

void ManagePermissions()
{
  std::bitset<MaxPermissions> user_rights;
  user_rights.set(Permission::Read);    
  user_rights.set(Permission::Write);   
  user_rights.flip(Permission::Execute); 
  
  if (user_rights.test(Permission::Write))
  {
    std::cout << "The user can write files.\n";
  }

  std::cout << "Current rights mask: " << user_rights << "\n";
}

int main()
{
  ManagePermissions();
}

The main advantage of std::bitset is that it protects against human error. If you pass an invalid index to one of its member functions—std::bitset<N>::set, std::bitset<N>::reset, std::bitset<N>::flip, or std::bitset<N>::test—such as index 15 for a four-bit bitset, the function throws a std::out_of_range exception. With manual bit masks, the same mistake could lead to unpredictable reads from unrelated memory or corrupt adjacent data.

There’s a caveat, though: std::bitset typically rounds its internal storage up to the processor's native word size, so it can't save memory at the individual-bit level.

For large numbers of flags: the std::vector<bool> specialization

Using a regular bool array to manage a huge, dynamically sized array of Boolean flags wastes a lot of memory because each element occupies an entire byte. To fix this issue, the standard library provides a specialized version of std::vector: std::vector<bool>.

This container works differently from ordinary vectors. The standard library optimizes it for memory efficiency by packing bool elements bit by bit into larger integer types (machine words). Usually, it can store 32 or 64 Boolean values in a single memory block.

The following is an example of using a large dynamic array:

#include <vector>

std::vector<bool> feature_flags(10000, false);

void process_features()
{
  feature_flags[42] = true; 
  if (feature_flags[42])
  {
    // code
  }
}

Despite its convenience, std::vector<bool> is one of the most controversial features of the C++ standard. Developers should exercise caution when using it. Because it packs bits so tightly, its elements aren't actual bool objects in memory. As a result, you can't take the address of an element directly (the bool *ptr = &feature_flags[0]; code won't compile) or pass an element by reference or pointer. The [] operator returns a special temporary proxy object that mimics reference behavior rather than a reference. This is the trade-off for compressing data in dynamically allocated memory.

Conclusion

Well, that’s all I have for you today. What can I say? Bit fields in C++ perfectly embody the language’s philosophy. They give you complete freedom to cut out exactly one bit, then leave you alone to navigate the hidden landmines buried in compilers and system ABIs. Now that you’ve looked under the hood and seen how this intricate memory optimization coexists with platform-dependent chaos, there’s no room for illusions. Bit fields are a powerful tool for optimizing cache lines and working with hardware. However, they can also create hidden issues when you try to send a structure over the network. Now you know the rules of this low-level game. How you wield this power over memory in your own projects is up to you.

Get a free one-month trial

Pitfalls of bit fields in C++ was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hotspots and bottlenecks

The key task in optimization is to find hotspots, which are code fragments with a high computational load, and bottlenecks, which are components that limit overall throughput, and these problems usually fall into three categories, namely abstractions, smoothness, and hardware limitations.

Abstractions, or more precisely premature abstractions, add unnecessary layers to the engine architecture and make the whole system more complex than it needs to be, and the usual suspects here are multiple inheritance, one-size-fits-all solutions to game development problems, and heavy use of design patterns in places where simple procedural code would do the job just fine.

The same category includes writing beautiful code instead of fast code, when performance-critical sections get buried under unnecessary layers of ceremony and checks, which is exactly what the KISS principle warns us about.

Most developers agree that smoothness matters more than peak performance, and the things that work against it are well known, because sporadic memory allocations on the main thread make the frame rate uneven, algorithms with unpredictable complexity make frame times inconsistent, and blocking resource loads cause stuttering. A stable 30 FPS beats a frame rate that jumps between 60 and 20, because players feel those jumps immediately, which is why a consistent frame rate is such an easy-to-understand and measurable indicator of quality.

Hardware limitations are best treated as creative constraints, because brute-forcing a platform’s physical limits instead of applying smart optimizations only adds complexity without any real payoff. Raising the polygon count without a proper level-of-detail system will leave the player with low FPS, and the same goes for complex shaders that ignore fill-rate limits, memory-hungry data structures that don’t account for the cache hierarchy, and so on.

A modern CPU-GPU architecture is a complex data-processing pipeline with many parallel execution units, and in this “digital hell” data moves through a hierarchy of caches, travels between the CPU and GPU over the bus, and gets synchronized across threads with memory barriers and atomic operations, so the system almost never does exactly what you wrote in the code.

You can get solid and stable performance by balancing the workload across all of these components, and even then you may not be able to push the CPU beyond 70 to 80%, but you can make much better use of the GPU, memory bandwidth, and caches. The real challenge is finding a delicate balance right at the edge of what’s possible for every component at once, and if you get it wrong, resource contention follows, one component becomes the critical link, and the rest of the system suffers from pipeline stalls, context-switching overhead, and reduced throughput.

Hotspots

In software systems, hotspots are localized sections of code with unusually high resource consumption, whether that’s CPU time, memory, or disk I/O, and they’re characterized by a disproportionately high execution frequency, heavy CPU utilization, high memory pressure, or significant system call overhead.

In the context of code optimization, the Pareto principle, also known as the 80/20 rule, means that 20% of the source code accounts for 80% of a program’s total execution time, which makes hunting down hotspots a highly effective strategy. Searching iteratively helps you find the code blocks that consume the most resources so you can target them and cool them down, but once one issue is fixed, the workload shifts and previously minor sections turn into new hotspots that need attention. This process goes on until the results are acceptable or the time allocated for the task runs out, and it’s worth remembering that an engineer’s time is a finite resource too, because the more time a developer spends polishing one part of the code, the less time they have for everything else.

Modern profilers provide detailed analysis down to the level of individual CPU instructions, which makes it possible to identify temporal hotspots, code with a high number of cache misses, heavy I/O operations, and resource-lock contention in multithreaded applications.

Bottlenecks

Imagine a dish being prepared in a café. The chef can’t make the whole thing at once, so they hand the side dish off to an assistant while working on the main part themselves, and then the two parts come together and a waiter takes the finished plate to the customer. How long will the whole process take? Suppose the chef finishes first, but the assistant simply can’t work any faster, and now the assistant is the bottleneck that slows down the entire system.

Games work exactly the same way, because there’s always a “slow assistant” somewhere, whether it’s the CPU, the GPU, memory, or something in the code that holds everything else back, and the developer’s job is to find that weak link and bring its performance in line with the rest. Optimization almost always involves trade-offs, and in 99% of cases there’s no silver bullet that will fix the problem right away.

The first and most common trade-off is between performance and memory, since sometimes it’s more efficient to store extra data than to recalculate it from scratch. This is called memoization or caching, and the idea is that you calculate something once, store the result, and then simply pull it from memory whenever you need it, which costs more memory but gets you the result faster.

The second trade-off is between accuracy and speed. Sometimes you can cut corners and speed up a system by simplifying a data type or using a less precise algorithm, and shaders are a good example, because they provide both log and logp, where the former is more accurate but slower and the latter is faster but less precise. In the final image, players are unlikely to notice that a neighboring polygon has shifted by a quarter of a pixel, but the game may run noticeably faster, and the same principle applies to almost any data model, pathfinding system, or game AI. The key question is how much precision you're willing to give up, or, in more formal terms, how much you can shift resources from lower-priority computations to higher-priority ones.

The third classic trade-off is simplicity versus speed, and this one has more to do with people and the team than with hardware. A classic example is a young, talented developer who has just discovered design patterns and responds by building five levels of nested caching in an attempt to optimize the texture-loading system.

Sure, they’ll get that system built, and it may even run faster thanks to intrusive pointers, custom allocator pools, and a lock-free hash table, but the result is predictable, because nobody, not even the author a month or two later, can understand, debug, or modify that code without risking breaking something. Other developers on the team start avoiding those files, they groan every time they have to touch the system, and code reviews keep getting comments like “What the hell is this? Can we just rewrite it in plain C++?”

An experienced developer knows that real performance gains don’t come from showing off their knowledge of algorithms, but from understanding the trade-off between how maintainable the code is and how much the optimization actually pays off.

Yes, you can squeeze out another 5% of performance with custom memory pools, but that will take two weeks to implement and another month to debug all the weird edge cases, so it might be smarter to use a simple linear allocator and trade some memory for time.

Mature optimization means fixing the truly critical bottlenecks with clean, well-documented solutions that you can easily switch off with conditional compilation if something goes wrong. In the real world, shipping the game matters more than cool algorithms, and having code the team can maintain matters more than having code that looks impressive in a conference talk.

Myths and misconceptions

Software optimization is inherently endless, because there will always be something left to improve, but it’s important to understand that past a certain point you start hitting diminishing returns, and every additional effort delivers a smaller and less noticeable performance gain.

On top of that, developers often spend time chasing dead ends that provide no real benefit (but make for great slides and conference talks) and only make the system harder to maintain. The key skill here is knowing when to stop and ask whether further improvements will actually add value or turn into a witch hunt.

One of the most common mistakes is making decisions based on assumptions. You can’t just “guess” what’s slowing the system down, because those guesses are usually wrong, and the only reliable approach is to measure and analyze, then analyze and measure again, until guesses and gut feelings turn into well-founded engineering decisions.

Optimization doesn’t start after the code is written, and in fact 80% of performance problems can be eliminated at the architecture design stage, because proper decomposition, a clear object hierarchy, and well-thought-out dependency management help you avoid bottlenecks in the first place. Despite the overhead that comes with languages like C# and Java, a well-structured system often outperforms code written in pure C++ that ignores architectural constraints.

When it comes to optimization, it’s important to focus on worst-case scenarios rather than average ones. Most developers test their games and applications on powerful workstations, which often gives them a distorted picture, and on weaker hardware the bottlenecks can be completely different, with memory bandwidth or CPU power becoming the limiting factor instead of the GPU.

To analyze performance properly, developers need to deliberately test on configurations with minimal or weak hardware specs, because those machines are much closer to what a good portion of your players actually experience. Players can tell the difference between 55 and 60 FPS, but they rarely complain about it, while a drop to 20 FPS feels like serious lag even if it only happens once in a while, and that’s why consistent frame times often matter more than a high average frame rate.

Debug and release builds give fundamentally different results (Pic. 3.1). In debug mode, compiler optimizations are turned off and extra checks are turned on, which can slow the code down several times over, and not evenly. For valid performance profiling, work only with release builds and enable debug symbols or disable optimization for specific sections when you need to, because this lets you strike a balance between traceability and accurate measurements while still giving you a realistic picture of performance.

Picture 3. 1

That said, debug builds are useful in the early stages of testing, when they can reveal excessive CPU usage or inefficient algorithms before those problems become critical.

Finally, the key requirement for any benchmark is control over external variables, since poorly designed tests can create the illusion of optimization. For example, the first measurement might be taken in fullscreen mode while the second runs in windowed mode, at a different refresh rate, or at a different resolution, and the frame rate goes up because the environment changed rather than the code, which makes the whole comparison meaningless. To avoid mistakes like this, keep every environment parameter fixed and change only one thing between runs, namely the piece of code you’re optimizing. The best practice is to automate your benchmarks, which removes human error and gives you reproducible results.

Many people think optimization time should be added to sprints once the game is nearly finished, or, even worse, only when performance problems show up. But ignoring optimization in the early stages of development means risking increasingly tangled processes and unpredictable performance problems at the worst possible moment.

Another myth is that reactive optimization works well enough on its own. Yes, hundreds of games ship after being optimized at the last minute, but this approach usually ends with cutting features or simplifying mechanics to make up for low FPS. Reactive optimization creates a false sense of control, because fixing problems late in development takes far more time and effort than taking a systematic approach throughout the whole project.

The next myth is that optimization needs large, dedicated blocks of time, when in reality it’s much more effective to work it in gradually. With practices like performance budgets, you can set limits for FPS, CPU, and GPU usage up front and organize the team’s work around those numbers, and continuous monitoring with incremental code adjustments produces better results than occasional optimization pushes in the final weeks of development.

There’s also a persistent belief that every optimization is justified. In reality, there are plenty of areas where programmers can sink time without seeing any obvious benefit, so only optimize what actually affects performance and weigh the potential payoff against the time the changes will take. This approach keeps you from wasting effort and keeps the focus on the bottlenecks that are really slowing the game down.

Finally, there’s a misconception that performance is a single metric, when a game that “feels slow” can mean any combination of low FPS, longer response times, high CPU and GPU load, and frame rate drops. To optimize even one of these metrics effectively, developers first need to understand which ones are critical for their particular project, how they relate to each other, and what’s actually holding the game back.

A systematic approach like this is the only way to avoid the common misconceptions about optimization. Will anyone actually approve such changes, though? Most likely not, because it’s extremely unlikely that the project architect, tech lead, or CTO will sign off on real architectural changes, and that’s not really the programmer’s call to make anyway, so pushing for it tends to step on the architect’s toes. Besides, changing an existing, working, well-tested system can break the systems around it, and there’s no way to predict when the error will surface, only that it inevitably will. That’s exactly why a developer who just joined the team can’t rewrite half the engine “the right way,” and what’s left for them is code-level and algorithmic tweaks, which can still squeeze out a performance improvement of at least 10%.

This brings us to the reality that game development forces us to balance our “ideal” technical solutions against the practical constraints of the project. Even a programmer who sees through every optimization myth often has to work within an existing architecture they can’t change and settle for local improvements at the algorithm and code level, but this approach can still deliver tangible results, such as the 10 to 15% performance gains that can make all the difference for a successful release.

Knowing where your influence ends matters, and so does choosing your battles wisely. Optimization was never just a technical skill, because it’s also a team sport where every change needs to be justified, measured, and agreed upon, and in the end the best optimization is the one players actually notice, not the one that gets you a few nods in a technical chat.

Tools

Any work aimed at improving performance is wasted if you can’t see what’s actually happening in your code. It’s like trying to repair a watch blindfolded or tune a musical instrument with your ears plugged, because you can turn the screws and pluck the strings all you want, but the result will be purely random.

In everyday life, we get immediate feedback, so if you trip, you fall, if you take a wrong turn, you may end up at a dead end, and if you add too much salt, you ruin the dish. These signals help us correct course right away and remember not to make the same mistake twice. In programming, however, things work differently, because code can execute millions of times per second, process gigabytes of data, and interact with dozens of system components, while all we see is the end result, say, an FPS counter that refuses to go above 50.

Modern software, and games in particular, can run to hundreds of thousands of lines of code stacked on top of complex operating systems, graphics drivers, and various libraries that add even more code. Without specialized analysis tools, all you can really do is guess whether the CPU can’t keep up, whether the bottleneck is loading textures from disk, or whether memory is leaking somewhere. Profilers, performance monitors, and debuggers can mislead you too, but you can’t do without them, because they show which functions take the longest to execute, how much memory each part of the program uses, how often the application hits the disk, and where the CPU sits idle waiting for data. Without this information you’re flying blind, and with it the solution often becomes obvious, although measuring and analyzing performance correctly is its own kind of science that sometimes borders on alchemy.

Any tool that measures a program’s performance will inevitably affect that performance. Some tools are light enough on their feet that they barely slow the program down, and those are called non-intrusive, while others can seriously drag down an application’s performance, and those are called intrusive.

How much interference you get depends on how much data you need and how often you need it. A simple FPS counter has virtually no impact on the game, while a detailed analyzer that logs every function call and its execution time can slow things down considerably. Some tools, such as Valgrind, go even further and run the entire program inside a virtual machine to collect highly detailed information about every operation, and you can guess what that does to performance, since the program can easily run ten times slower than usual or worse.

There are several ways to measure performance, and sampling profilers are the gentlest and simplest of them. They periodically take a snapshot of the program to see which code is running at that moment, and by collecting a series of these snapshots, developers can build a statistical picture of what the program spends most of its time doing.

A more intrusive approach relies on interception tools that sit between the program and external resources, so PIX, for example, intercepts every call the program makes to the GPU through the DirectX API, while network analyzers peek at all network traffic.

Getting even more detail means adding special commands and profiling markers to the code to collect data, and this process is called instrumentation.

Choosing the right tool depends on your specific goals and on how much performance you’re willing to sacrifice for a more detailed analysis. The one rule that really matters is that the tool shouldn’t distort the measurements more than the problem you’re hunting for, since there’s little point in optimizing a function that accounts for only 1% of execution time if the profiler itself slows the program down by 50%. That’s why all three types of tools are often used, each in its own circumstances.

Theory and terminology

Profilers is an umbrella term for the performance analysis tools used across most of game and software development, and a profiler’s main job is to capture how the workload breaks down during execution in as much detail as the developer allows.

The classic use case is measuring CPU time, but modern profilers can track much more, including cache misses, memory allocations, disk access, thread usage, and synchronization. Depending on the level of instrumentation, they can give you either an aggregated view of the workload that shows which modules or systems put the most load on the CPU and where, or a per-frame or per-interval snapshot with the call stack and the exact distribution of work across individual instructions.

Profilers fall into two categories, general-purpose and specialized. General-purpose profilers are usually the ones built into an IDE or a platform SDK, such as the Visual Studio Profiler, and they give you a broad sense of where performance is leaking. Specialized profilers are low-level tools, such as Sony Razor, Intel VTune, PIX, or Tracy, that collect data from CPU performance counters and OS events and let you analyze code behavior with much greater precision, and only these low-level tools let developers evaluate how specific algorithmic steps or memory access patterns affect the overall performance of a piece of code.

Total time shows the cumulative execution time of a function, including all the nested calls it makes to other functions. In theory, it helps identify hotspots in an application and gives a complete picture of how much time the program spends in a particular section of code along with all its dependencies, but in practice it can give a distorted view of performance.

As part of its optimizations, the compiler may inline functions directly into the code of the calling function, which blurs the execution time of the parent function even though the inlined code is what actually does the work. This metric also doesn’t account for indirect costs, such as cache pollution or data eviction, which can seriously undermine how reliable the measurement is.

For example, when you analyze functions whose performance depends heavily on their input data, such as sorting an almost-sorted array versus an unsorted one, the profiler will report an average value, which can hide real performance problems that only show up in certain use cases.

Self time measures only the time spent executing instructions inside the function itself, excluding the time spent in all the functions it calls. This helps identify the code blocks that actually do the expensive work rather than just handing it off to other functions, and functions with heavy algorithms, loops, or number crunching typically show high self time.

The ObjectUpdate() function may have a high total time because it calls all the other subsystems responsible for updating the game state, but a low self time because it doesn't do much work on its own, while a collision-physics function may show significant self time, which tells you that this particular section needs optimization. The problems here are much the same as with the previous metric, because self time can't reflect a function's actual impact on the overall performance of the system. A function may have a low self time while triggering many expensive operations through other functions, which creates a false impression of efficiency. On top of that, this metric ignores function call overhead, so if a function makes thousands of small calls, the cost of creating stack frames, passing parameters, and returning values can be significant, or even close to the actual execution time, and still stay invisible in the self-time numbers.

Another issue is “aggressive optimization,” which is especially common with Clang-based compilers that inline small functions and partially embed their code at the call site. As a result, self-time measurements get distorted, because code that belongs to a different function is counted as self time for the caller (Pic. 3.2).

Picture 3. 2

The Calls metric shows how often a particular piece of code runs during a profiling session, which helps reveal how different functions are actually used in the application. Even if their individual execution times are short, functions with a high call count are good candidates for optimization, because the cumulative overhead of all those calls can be significant.

Analyzing call counts is one of the first steps in finding inefficient algorithms or unnecessary computations (with one caveat, which is covered in the note below). A function that gets called thousands of times per frame may need a whole range of optimization techniques, and a high call count can also point to recursion, resource leaks, or other architectural problems in the application (Pic. 3.3).

Picture 3.3

Overall, this is a fairly useful metric, but the call count alone doesn’t show how those calls are distributed over time. A function may be called 100,000 times in a session, but if all those calls happen while a level is loading, they have no impact on gameplay performance, and in that case the profiler will show a high call count without telling you that the function sits idle while frames are being rendered. The call count can also be misleading when it comes to spotting real architectural problems, because a high number of calls may simply be the result of a well-designed architecture with lots of small, specialized functions rather than a sign of inefficiency.

NOTE

Modern compilers have gotten very good at inlining, so focusing only on call counts can lead to premature or incorrect conclusions.

Total waste time tracks how long a function spends with its thread blocked while waiting for resources to become available, I/O operations to complete, or system events to occur (Fig. 3.4). This time doesn’t reflect active execution of the function, but rather delays caused by external factors, and a high waste time can point to indirect performance problems that affect the function’s overall execution time. This metric is usually analyzed when refactoring code or reducing dependencies between functions.

Picture 3.4

Author: Sergei Kushnirenko

Sergei has over 20-year experience in coding and game development. He graduated from ITMO National Research University and began his career developing software for naval simulators, navigation systems, and network solutions. For the past fifteen years, Sergei has specialized in game development: at Electronic Arts, he worked on optimizing The Sims and SimCity BuildIt, and at Gaijin Entertainment, Sergei headed up the porting of games to the Nintendo Switch and Apple TV platforms. Sergei actively participates in open-source projects, including the ImSpinner library and the Pharaoh (1999) game restoration project.

All parts

• Game++. Part 1.1: C++, game engines, and architectures
• Game++. Part 1.2: C++, game engines, and architectures
• Game++. Part 1.3: C++, game engines, and architectures
• Game++. Part 1.4: C++, game engines, and architectures
• Game++. Part 2.1: Types of optimization

Game++. Part 2.2: Types of optimization was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Union types

We’ll start with the most straightforward change, union types. They enable developers to combine types without relying on inheritance or interfaces where it's unnecessary or unavailable. A union is a structure that contains the complete set of supported types.

public union TestUnion(int, Version, IEnumerable<string>);

In the code above, union is the keyword, while int, Version, and IEnumerable<string> are the set of supported types.

The union types come in handy when traditional inheritance isn't an option, as it requires the types to have something in common. However, there may be cases where inheritance is impossible or makes little architectural sense. We might need to handle a specific set of types, including primitives. Normally, we'd have to specify a variable of the object type as input and then cast it to the required types within the method, including logic for handling anything unsupported. That's error-prone. Using union in this situation would solve these problems, making the code safer and easier to read.

Given the nature of the new structure, when we use union, the compiler already knows the complete list of types it can contain. So, the default branch is no longer necessary. The change protects us from a switch that misses some types while new subclasses keep falling into the default section, which can cause unpredictable program behavior.

Let’s look at a more specific example. Before this update, we’d have had to write something like this to define a method for handling API responses:

public abstract record ApiResult;

public record ErrorData(string Message);
public record Success(string Data) : ApiResult;
public record ValidationError(ErrorData Data) : ApiResult;

public string Process(ApiResult result)
{
  return result switch
  {
    Success s => s.Data,
    ValidationError s => s.Data.Message,
    _ => "Unknown result"
  };
}

The ApiResult abstract class, from which specific responses inherit, is declared. So, if a new subclass appears and the developer fails to handle it, executions falls into the default branch. With a union, it works differently:

public record ErrorData(string Message);
public record Success(string Data);
public record ValidationError(ErrorData Data);

public union ApiResult(Success, ValidationError)
{ 
  public string GetData()
  {
    return this switch
    {
      Success s => s.Data,
      ValidationError s => s.Data.Message
    };
  }
}

As you can see, there’s no need for a parent class just to group the types together. The behavior is also more predictable because the compiler knows at compile time exactly which types union can contain. So, if a switch doesn't handle every type in the union, the compiler issues a warning.

Moreover, the union gives developers an easier way to express patterns such as monads. It also enables implementing custom methods and properties within union, so working with all its types doesn't require writing switch.

Closed hierarchies

This change is somewhat related to union in that it also lets the compiler know exactly how many types it'll work with. It does so by preventing inheritance from a class outside the assembly where it was declared. This behavior resembles a mix of internal and sealed: it takes the scope from internal and the restriction on inheritance from sealed. This can be useful, for example, in libraries where we want to restrict inheritance from certain classes without blocking it within our own assembly. Here's an example declaration:

public closed record ClosedRecordClass;

The closed keyword marks the class as closed to inheritance. As a result, attempting to inherit from such a class in another assembly causes a compilation error. Note that, like union, a closed hierarchy supports an exhaustive switch, which enables omitting the default branch.

A few important details are worth keeping in mind. Firstly, a class marked as closed is always abstract. This also helps enable an exhaustive switch. Secondly, descendants don't automatically become closed. If we need to hide them from other assemblies, we can mark them with the internal access modifier. Thirdly, only classes (class and record class) can be closed to inheritance from another assembly. Structs don't support inheritance, while interfaces are specifically designed to be inherited from. So, adding the keyword to a struct or an interface will result in a compilation error.

Labeled break and continue

A small but quite important addition: most of us have probably run into situations where we needed to interrupt the execution of an external structure or skip to its next iteration. The classic approach would have looked something like this:

public enum WorkItemType
{
  Process,
  StopAll
}
public class WorkItem
{
  // ....
  public WorkItemType Type { get; set; }
}

public class OldLabeledBreak
{
  public void PerformAction(IEnumerable<WorkItem> workList)
  {
    bool stopProcessing = false;

    foreach (var item in workList) // #1
    {
      switch (item.Type) // #2
      {
        case WorkItemType.Process:
          // ....
          break; // break #2
        case WorkItemType.StopAll:
          stopProcessing = true;
          break; // break #2
      }

      if (stopProcessing)
        break; // break #1
    }
    // ....
  }
}

In other words, we need an additional flag so that the outer loop can exit after the inner switch finishes executing. Of course, we could use goto, but it can make the code harder to follow because the label code execution jumps to can appear anywhere. Labeled break and continue simplify this. Let's see what this method would look like now.

public void PerformAction(IEnumerable<WorkItem> workList)
{
  outer:  foreach (var item in workList) // #1
  {
    switch (item.Type) // #2
    {
      case WorkItemType.Process:
        // ....
        break; // break #2
      case WorkItemType.StopAll:
        break outer; // break #1
    }
  }
  // ....
}

As you can see, the syntax is similar to goto, while the code becomes more readable. This lets us avoid creating extra flags and checks, which can slightly reduce memory usage and also make the code more expressive. Labels can be applied with the following constructs: for, foreach, while, do, and switch.

Extension indexers

This change enables developers to define how collection elements can be accessed by index using extension indexers. For example, it’s possible to implement element access with Range for IReadOnlyList. Before C# 15, we could implement this as follows:

public class OldExtensionIndexers
{
  public void Process()
  {
    IReadOnlyList<string> readOnlyList = ["val1", "val2", "val3"];
    var elem = readOnlyList.Slice(..2);
  }
}
public static class OldReadOnlyListExtensions
{
  public static IReadOnlyList<T> Slice<T>(this IReadOnlyList<T> list, 
                                          Range range)
  {
    var (offset, length) = range.GetOffsetAndLength(list.Count);
    var result = new List<T>(length);
    for (int i = 0; i < length; i++)
      result.Add(list[offset + i]);
    
    return result;
  }
}

While a regular extension method already solves this problem, C# 15 introduces the option to create extension indexers. So, we’ll get access to elements using the familiar brackets. Let’s look at how this would work in our example:

public class NewExtensionIndexers
{
  public void Process()
  {
    IReadOnlyList<string> readOnlyList = ["val1", "val2", "val3"];
    var elem = readOnlyList[..2];
  }
}
public static class NewReadOnlyListExtensions
{
  extension<T>(IReadOnlyList<T> list)
  {
    public IReadOnlyList<T> this[Range range]
    {
      get
      {
        var (offset, length) = range.GetOffsetAndLength(list.Count);
        return list.Skip(offset).Take(length).ToList();
      }
    }
  }
}

It’s worth noting that if a type has its own indexer, it takes precedence over an indexer declared as an extension. The official order of precedence is as follows: explicit type indexers, implicit type indexers, explicit extension indexers, and implicit extension indexers.

Collection expression arguments

The next feature will help shorten code and make collection initialization more convenient by passing the required arguments directly to the constructor. For example, we can pass capacity and comparer. In C# 14 and earlier, we would need to write something like this:

public void ProcessList()
{
  List<string> loginList = ["login1", "login2"];

  List<string> newLoginList = new List<string>(loginList.Count);
  newLoginList.AddRange(loginList);
}
public void ProcessHashSet()
{
  HashSet<string> hashSet = new HashSet<string>
(StringComparer.OrdinalIgnoreCase);
  hashSet.Add("value 1");
  hashSet.Add("value 2");
}

The initializer supports only one option because List has just three constructors: an empty one, one that takes capacity, and one that takes a collection. Let's look at the new possible implementation:

public void ProcessList()
{
  List<string> loginList = ["login1", "login2"];

  List<string> newLoginList = [with(loginList.Count), ..loginList];
  // newLoginList.AddRange(loginList);
}
public void ProcessHashSet()
{
  HashSet<string> hashSet = [with(StringComparer.OrdinalIgnoreCase), 
    "value 1", "value 2"];
  // hashSet.Add("value 1");
  // hashSet.Add("value 2");

}

The code looks cleaner, right? Your IDE will probably even suggest this syntax and collapse everything into a single line. However, note that with must always come first; otherwise, the compiler will issue an error.

Memory safety

The final change involves reevaluating what C# considers unsafe. The language team aims to flag only code that actually accesses unmanaged memory as unsafe. In other words, using pointers will no longer automatically make code unsafe. Before C# 15, unsafe code was marked like this:

public unsafe class OldMemorySafety
{
  public int ReadMemory(byte* ptr)
  {
    return *ptr;
  }
  public int Process()
  {
    byte b = 42;
    byte* newPtr = &b;
    return ReadMemory(newPtr);
  }
}

Any use of pointers used to require the unsafe keyword. To better understand the change, let's take a look at what the code will look like in the new version:

public class NewMemorySafety
{
  public int ReadMemory(byte* ptr)
  {
    unsafe
    {
      return *ptr;
    }
  }
  public int Process()
  {
    byte b = 42;
    byte* newPtr = &b;
    return ReadMemory(newPtr);
  }
}

We no longer need to mark the class as unsafe. Instead, the keyword goes only where it's needed. In this case, dereferencing the pointer is unsafe, so it should be marked as such.

The safe keyword has also been added. It should be used when a block contains unsafe operations that are safe for the caller's context, so callers don't require the unsafe block. In other words, use safe when the compiler can't verify safety on its own. Examples include extern methods and fields in structs with explicit memory layout ([StructLayout(LayoutKind.Explicit)]).

It’s also worth mentioning stackalloc. Its use is now considered unsafe when all of the following apply: it's converted to Span<T> or ReadOnlySpan<T>, it has no initializer, and it's used where SkipLocalsInitAttribute is present.

The new rules introduced by this change should be enabled separately. If you’d like to learn more, follow this link for the official instructions.

Conclusion

This year’s language release has brought developers a number of fairly important features. Among them are useful additions such as union types and closed hierarchies, while several other changes simplify common coding patterns, making development little smoother once again. Some of these features may not become as popular, but that doesn't make them any less useful to certain groups of developers. Which of these changes did you find most useful? Share your thoughts in the comments!

You can read the C# 15 documentation via this link. Don’t forget to check out our overviews of previous versions, here’s the list:

• What’s new in C# 9: overview
• What’s new in C# 10: overview
• What’s new in C# 11: overview
• What’s new in C# 12: overview
• What’s new in C# 13: overview
• What’s new in C# 14: overview

What’s new in C# 15: Overview was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

OWASP Benchmark for Java

In this release, we checked the Java analyzer SAST rules against the OWASP Benchmark for Java.

Evaluating the quality of security-related diagnostic rules on real-world projects can be quite challenging. We can’t predict how many vulnerabilities the code will contain, so we can’t determine which defects the analyzer has overlooked.

We used the benchmark to address gaps in the Java analyzer SAST capabilities, which made the tool more effective at detecting security defects.

New versions of Java and Go

With the release of PVS-Studio 8.01, we’ve added support for the latest platform versions. The Java analyzer now supports JDK 25, and the Go analyzer supports Go 1.27.

This enables teams to analyze projects using the latest language versions and standard libraries without delaying updates due to limitations in their analysis tools.

JDK 25 is also an LTS release, making its support particularly important for teams migrating to a new long-term support version.

Reports with analysis configuration details

The PVS-Studio_Cmd.exe utility for analyzing MSBuild projects now includes in JSON reports the project configurations used during analysis. This makes it easier to fix warnings that occur on specific platforms.

In addition, the fullhtml report generated by PlogConverter.exe now groups warnings by analysis configuration.

Expanded configuration options

This release expands the configuration options for our analyzers and utilities, making them easier to tailor to specific project requirements and environments.

The JavaScript and TypeScript analyzer now supports the max-old-space-size setting. You can find it in the pvs-settings.toml configuration file and the pvs-js.exe command-line utility. This setting enables you to specify how much memory the analyzer's Node.js server can use.

In PVS-Studio_Cmd.exe, you can now specify dependency cache paths relative to the .pvsconfig configuration file.

The C and C++ analyzer now offers more options for configuring diagnostic rules. Now, you can specify custom types as “cheap-to-copy,” and configure the analyzer behavior based on the target platform.

The V719 diagnostic rule now supports additional configuration options: ignoring default branches and small enum types, specifying individual values to ignore, and setting the maximum number of constants that can be ignored.

Extended warning filtering

The Plog Converter utility for converting and filtering reports now allows you to filter diagnostic rules by CWE codes and SAST identifiers.

Breaking Change

This release includes a change that breaks backward compatibility with previous versions of the analyzer. You may need to adjust how you use the analyzer due to these changes.

The PVS-Studio installer for Windows now returns exit code 100 if Visual Studio plugin installation fails. We also added the skipVSIXInstallErrorCode flag to disable the non-zero exit code in this case.

New diagnostic rules

Java

• V5341. OWASP. A cookie was created without enabling the ‘Secure’ attribute. This may lead to the exposure of sensitive data.
• V5342. OWASP. Potentially tainted data is stored in an object that can be used as a source of trusted data.
• V5343. OWASP. A cryptographically weak random number is used for sensitive data.

Articles

Here’s the traditional roundup of posts from our blog! Over the past two months, we’ve published articles where we looked for bugs in the popular C# ORMs, RepoDB and SqlSugar, reviewed VSCode source code, explored the new features of Java 27, found bugs in the Create mode, and much more. The full list is below:

C and C++

• The worst programming language of all time /s

C#

• What popular ORMs for C# hide: Let’s check RepoDB and SqlSugar

Java

• What’s new in Java 27
• I found some bugs in Create mod and checked them in Minecraft

JavaScript and TypeScript

• We checked the source code of VS Code

Go

• PVS-Studio for Go: Quick overview of new diagnostic rules

Security

• Avoid adding new library to project: 10-year retrospective

Other

• Why do we integrate PVS-Studio analyzer with so many tools?

Webinars

Let’s make a programming language. Variables

We continue building our own programming language from scratch. In this video, we’ll take the next step by adding variables to the language.

So far, our programs have consisted of a single expression built from smaller language constructs. Now it’s time to evolve the language. Instead of parsing a single expression, we’ll introduce a list of declarations, allowing our language to support variable declarations and laying the groundwork for more complex programs.

During the video, Yuri will walk through the implementation step by step, showing how variables are represented and processed in our language, and how to add this functionality to your language in C++.

This video is designed for developers who want to understand how programming languages work under the hood — not just how to use them.

Go-Go-Gadg…Error? A closer look at the mistakes Go developers make!

Mistakes happen in Go code just like in any other language: typos, duplicates, broken condition checks, and so on.

But why do they still slip through? After all, many teams use tools like go vet, which catches all of this perfectly well… right?

In this webinar we covered:

• Common mistakes in Go code, straight from well-known projects;
• Errors that standard tools and approaches fail to catch, and how to handle them.

Let’s make a programming language. Functions

We continue building our own programming language from scratch.

In the previous session, we introduced variables — they could be declared, reference one another, and were resolved through a global hash table. Now it’s time to add one of the core building blocks of any language: functions. Implementing functions is really a story about scopes and name resolution. We’ll explore how identifiers are looked up across different scope levels: the global scope, function scopes with their own variables, and nested local scopes inside function bodies. What happens when the same variable name exists in multiple scopes? How does the compiler determine which one to use?

In this video, we will walk through the implementation step by step, demonstrating how functions, scopes, and symbol lookup are built in code using C++. Along the way, you’ll gain a deeper understanding of one of the fundamental mechanisms behind modern programming languages.

Let’s make a programming language. Evaluator

We’re reaching the final stage of our journey of building a programming language in C++!

So far, we’ve created a lexer, a parser, and an AST. Now it’s time to make our language do what it was designed to do — evaluate expressions.

In this webinar, we’ll explore how to represent the results of computations in our language and learn how to evaluate expressions step by step. By the end of the session, we’ll bring all the pieces together and complete our own programming language.

Go vet can’t go: How to create your own Go analyzer?

A static analyzer is a powerful dev tool, and any Go developer who has worked with go vet knows it. But what if its capabilities aren’t enough? Would you look for a new tool, or… build your own?

In this live talk, PVS-Studio’s Developer Advocate walks through Go’s built-in tools and code-parsing capabilities, explains the basics of static analysis, unpacks what a semantic model is, shows how to build a syntax tree, and much more.

The end goal? Build your own static analyzer, tailored to catch what matters most in your projects.

Bugbusters

This is the first episode of our new podcast, Bugbusters. Our guest is Nathan Baggs, a content creator and YouTuber. We discussed whether it’s worth learning C++ in 2026, how the language is evolving, what it’s used for, and what its drawbacks are. We hope you enjoy this episode! We look forward to your comments!

Conclusion

If you would like to receive news about PVS-Studio releases, subscribe to our newsletter here.

If you haven’t checked your project using PVS-Studio yet, start with a trial license.

PVS-Studio 8.01: OWASP Benchmark, JDK 25 and Go 1.27 support, and much more was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

PVS-Studio 8.00 was recently released, introducing several new major features, including the Go analyzer that comes with several new and cool diagnostic rules.

It includes a rule that detects one of the trickiest types of copy-paste bugs, the kind that can easily slip past a regular code review. Okay, now let’s take a look at the code:

if process.ProcessName != nil && 
   (len(*process.ProcessName) == 0 ||
   len(*process.ProcessName) > common.NameFieldMaxLength) {

  return kit.CCError.CCErrorf(common.CCErrCommParamsInvalid,        
                              common.BKProcessNameField)
}
....
if process.FuncName != nil && 
   (len(*process.FuncName) == 0 ||
   len(*process.ProcessName) > common.NameFieldMaxLength) {

  return kit.CCError.CCErrorf(common.CCErrCommParamsInvalid, 
                              common.BKFuncName)
}

You’ve probably noticed that the expressions in both if statements consist of the same checks, but they aren't completely identical: the first one uses process.ProcessName, while the second one uses process.FuncName in the same positions. Or... does it?

The last checks suspiciously break this pattern: they’re exactly the same, and both use the process.ProcessName field. Based on the logic the code has consistently followed so far, the check in the second if should have used a different field, process.FuncName.

Since such typos can easily slip past manual review, the best solution is to delegate the task of catching them to a static analyzer. But how can we teach a program to compare similar yet distinct code fragments and use those comparisons to detect bugs the way humans do? Is AI necessary for that? In the rest of this article, we’ll explore these questions by looking at how the diagnostic rule works in PVS-Studio for Go.

How does the analyzer find these bugs?

Modern AI models can indeed detect such bugs. However, integrating artificial intelligence into a static analyzer for such a purpose is too expensive and resource-intensive.

Fortunately, we don’t need AI here. We can handle the task with a relatively simple heuristic algorithm. We’ll take a closer look at how it works later, but first, let’s go over a few basic concepts from static code analysis:

• Statements are the elements of code that form its skeleton and describe the execution flow (if, switch, for, and {...} blocks).
• Expressions are code elements that manage data (function calls, variables, and operators).
• Nodes is a general term for statements, expressions, and other types of code elements.
• Abstract Syntax Tree (AST) represents code as a hierarchical structure where some elements, like folders in a file system, contain other elements. An AST contains the same information you can get from the code itself, but its structured format makes it better suited for program analysis.

If you’re interested in delving deeper into static analysis, we have the perfect article for you.

Well, now that we have enough context, we’re ready to face the boss algorithm. Here’s how the V8033 diagnostic rule in PVS-Studio’s Go analyzer works:

• Within a function, the analyzer takes individual statements and groups of statements, separated by blank lines (hereinafter referred to as code fragments) and builds a simplified AST for them. Unlike a regular AST, it contains only the information needed to describe the code structure and omits specific names of variables, functions, and other semantic information.
• The fragments are grouped by their simplified AST. This is how fragments with similar structure are identified, even though they may still differ in their details (for example, in the variables they use).
• Within each group, the fragments are paired and compared with one another. Let’s look at how the algorithm works for a single pair. For convenience, let’s call the two fragments in one pair A and B.
• The analyzer identifies the variables that appear in both A and B (common variables) as well as the variables that appear in only one of the fragments (specific variables).
• Let’s assume that A is higher in the code than B. If one of the common variables occurs less frequently in B than in A, but still at the same relative positions, the uses of that variable in B are treated as potential typos.
• Next, a replacement candidate is sought among the B variables. This variable must be used in the same relative position as the previously considered general variable in A, but not in B.
• If the analyzer finds such a candidate, it performs a series of final checks to determine whether the variables are interchangeable. If all the checks pass, the developer receives warnings about possible typos in the code.

Of course, this is just a conceptual outline. A significant amount of important logic remains behind the scenes, especially the logic that filters out false positives. Without it, the diagnostic rule would be far less useful.

It is only 5% of the task to create the diagnostic. It’s not hard for the analyzer to complain about suspicious code, it’s much harder to not complain about the correct code. We spend 95% of our time “teaching” the analyzer to detect various programming techniques, which may seem suspicious for the diagnostic, but in reality they are correct.

From the article “How PVS-Studio does the bug search: methods and technologies”

Now that we’ve taken a quick look at how the analyzer works, let’s exercise in looking for similar errors on our own.

Find an error

I invite you to challenge yourselves by finding errors in this code, which was taken from real open-source projects. The closer you get to the end, the harder the examples become.

Are you up for the challenge? Let’s get started, then!

Yao Agents

Yao Agents is an open-source platform for creating and running autonomous AI agents. Its key feature is that the agents run directly on users’ devices, while all operations are centralized and controlled via a single interface.

We found this code in the v1.0.0-rc15 release:

func Generate(option Option) (string, string) {
  if option.Width == 0 {
    option.Width = 240
  }

  if option.Height == 0 {
    option.Width = 80
  }

  if option.Length == 0 {
    option.Length = 6
  }

  if option.Lang == "" {
    option.Lang = "zh"
  }
  ....
}

The analyzer’s hint:

V8033 Two similar code fragments were found. The second fragment may contain a typo: the “option.Height” variable should be used instead of the “option.Width”. captcha.go 48

CDS

CDS is an enterprise-grade platform for automating DevOps processes, continuous integration (CI), and continuous delivery (CD).

We found this code in the 0.54.1 release:

if conf.GraylogFieldCDSServiceName != "" {
  extra["CDSName"] = conf.GraylogFieldCDSServiceName
}
if conf.GraylogFieldCDSServiceName != "" {
  extra["CDSService"] = conf.GraylogFieldCDSServiceType
}
if conf.GraylogFieldCDSVersion != "" {
  extra["CDSVersion"] = conf.GraylogFieldCDSVersion
}
if conf.GraylogFieldCDSOS != "" {
  extra["CDSOS"] = conf.GraylogFieldCDSOS
}
if conf.GraylogFieldCDSArch != "" {
  extra["CDSArch"] = conf.GraylogFieldCDSArch
}

The analyzer’s hint:

V8033 Two similar code fragments were found. The second fragment may contain a typo: the “conf.GraylogFieldCDSServiceType” variable should be used instead of the “conf.GraylogFieldCDSServiceName”. log.go 107

BFE

BFE is a high-performance, application-level load balancer and reverse proxy server.

We found this code in the 1.8.4 release:

if cfg.Basic.WasmPluginPath == "" {
  ....
  cfg.Basic.WasmPluginPath = "mod_wasm"
}
cfg.Basic.WasmPluginPath = bfe_util.ConfPathProc(....)

if cfg.Basic.DataPath == "" {
  ....
  cfg.Basic.WasmPluginPath = "mod_wasm/wasm.data"
}
cfg.Basic.DataPath = bfe_util.ConfPathProc(cfg.Basic.DataPath, 
                                           confRoot)

The analyzer’s hint:

V8033 Two similar code fragments were found. The second fragment may contain a typo: the “cfg.Basic.DataPath” variable should be used instead of the “cfg.Basic.WasmPluginPath”. conf_mod_wasmplugin.go 63

Hertz

Hertz is a high-performance HTTP framework written in Go by ByteDance (the creators of TikTok), designed for building high-load microservices. It combined the concepts of popular Go frameworks (Gin, FastHTTP) with ByteDance’s internal requirements.

We found this code in the 0.10.6 release:

if goOptMapAlias[sb.Scope.GetOptions().GetGoPackage()] != "" {
  reqName = goOptMapAlias[sb.Scope.GetOptions().GetGoPackage()] + 
            "." + inputGoType.GoIdent.GoName
}
if goOptMapAlias[sb.Scope.GetOptions().GetGoPackage()] != "" {
  respName = goOptMapAlias[st.Scope.GetOptions().GetGoPackage()] + 
             "." + outputGoType.GoIdent.GoName
}

The analyzer’s hint:

V8033 Two similar code fragments were found. The second fragment may contain a typo: the “st” variable should be used instead of the “sb”. ast.go 233

Nuclei

Nuclei is a modern, high-performance vulnerability scanner that uses simple YAML-based templates. It enables users to create their own vulnerability detection scenarios that simulate real-world conditions, which eliminates false positives.

We found this code in the 3.11.1 release:

for _, tag := range config.ExcludeTags {
  for _, val := range splitCommaTrim(tag) {
    if _, ok := filter.block[val]; !ok {
      filter.block[val] = struct{}{}
    }
  }
}
for _, tag := range config.Severities {
  if _, ok := filter.severities[tag]; !ok {
    filter.severities[tag] = struct{}{}
  }
}
....
for _, tag := range config.ExcludeProtocols {
  if _, ok := filter.excludeTypes[tag]; !ok {
    filter.excludeTypes[tag] = struct{}{}
  }
}
for _, id := range config.ExcludeIds {
  for _, val := range splitCommaTrim(id) {
    if _, ok := filter.block[val]; !ok {
      filter.excludeIds[val] = struct{}{}
    }
  }
}

The analyzer’s hint:

V8033 Two similar code fragments were found. The second fragment may contain a typo: the “filter.excludeIds” variable should be used instead of the “filter.block”. tag_filter.go 434

LakeFS

LakeFS is an open-source data version control system for managing data stored in an object storage system. It enables Git-like operations like branching, committing, merging, and rolling back for large-scale data, stored in systems including Amazon S3, Azure Blob Storage, and Google Cloud Storage, as well as on other S3-compatible object storage platforms.

We found this code in the 1.86.0 release:

usersKey := model.GroupUserPath(groupID, "")

it, err := kv.NewSecondaryIterator(....)

if err != nil {
  return err
}
defer it.Close()
for it.Next() {
  entry := it.Entry()
  user := entry.Value.(*model.UserData)
  ....
}
if err = it.Err(); err != nil {
  return err
}

policiesKey := model.GroupPolicyPath(groupID, "")

itr, err := kv.NewSecondaryIterator(....)

if err != nil {
  return err
}
defer it.Close()
for itr.Next() {
  entry := itr.Entry()
  policy := entry.Value.(*model.PolicyData)
  ....
}
if err = itr.Err(); err != nil {
  return err
}

The analyzer’s hint:

V8033 Two similar code fragments were found. The second fragment may contain a typo: the “itr” variable should be used instead of the “it”. service.go 476

Vault

Vault is an open-source (BSL) tool for centralized secret management, data encryption, and for the protection of confidential information in cloud and hybrid infrastructures.

We found this code in the 2.0.4 release:

for name, crl := range h.CRLs {
  ....
  ratio := time.Duration(
    (int64(total) * int64(h.CRLExpiryPercentage)) / int64(100)
  )
  if used >= ratio {
    expWhen := crl.ThisUpdate.Add(ratio)
    ret.Status = ResultCritical
    ret.Message = fmt.Sprintf(
      ...., 
      crl.NextUpdate.Format("2006-01-02"), 
      h.CRLExpiryPercentage,   
      crl.ThisUpdate.Format("2006-01-02"), 
      expWhen.Format("2006-01-02")
    )
    ....
  }

  results = append(results, &ret)
}

for name, crl := range h.DeltaCRLs {
  ....
  ratio := time.Duration(
    (int64(total) * int64(h.DeltaCRLExpiryPercentage)) / int64(100)
  )
  if used >= ratio {
    expWhen := crl.ThisUpdate.Add(ratio)
    ret.Status = ResultCritical
    ret.Message = fmt.Sprintf(
      ...., 
      crl.NextUpdate.Format("2006-01-02"),
      h.CRLExpiryPercentage, 
      crl.ThisUpdate.Format("2006-01-02"), 
      expWhen.Format("2006-01-02")
    )
    ....
  }

  results = append(results, &ret)
}

The analyzer’s hint:

V8033 Two similar code fragments were found. The second fragment may contain a typo: the “h.DeltaCRLExpiryPercentage” variable should be used instead of the “h.CRLExpiryPercentage”. pki_crl_validity_period.go 195

Conclusion

Did you spot all the errors without looking at the hints? If so, that’s great! If not, don’t worry — that’s where a static code analyzer comes into play!

By the way, you can download it from our official website and try it for free on your own projects.

In addition to the Go analyzer, PVS-Studio 8.00 brought several other exciting features, including an analyzer for JavaScript and TypeScript. You can find more details about them in our article.

Happy coding!

When copy-paste goes wrong: Bugs in structurally isomorphic Go code was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Control Flow Graph?

I’ve touched on this topic before, in my series on taint analysis in Java, but let’s quickly recap it here. A static analyzer starts by converting source code into an abstract syntax tree (AST). It almost completely mirrors the structure of the code as you write it in the editor. That makes it a poor fit for anything involving control flow analysis, such as finding unreachable code. It’s possible to write a check for unreachable code on the AST, but:

• this would be unreliable in corner cases;
• this wouldn’t scale well to similar rules;
• this would be hard to maintain. Every bug fix or new language version would mean revisiting all of these diagnostic rules.

The Control Flow Graph (CFG) exists to address these issues; it maps out all possible execution paths in a program.

The CFG consists of three components:

• entry and exit nodes;
• Basic blocks nodes, each containing linear instructions;
• Each basic block ends with a terminator (or with nothing). A terminator is a special instruction that determines specific semantics for the execution flow: branching, break/continue, and so on.
• Edges between nodes that represent possible control flow transitions.

How did we do it?

Common CFG

In our article on developing the JavaScript/TypeScript analyzer, we mentioned that the tool includes not only a syntax tree for each specific language, but also a common one for multilingual analysis. We named it CAT (Common Abstract Tree).

No other languages have joined JavaScript/TypeScript yet, but we’ve already made the CFG extensible: the core engine doesn’t depend on any specific language. We define a set of multiple semantics and just combine them like building blocks into a CFG for a specific language we need. It’ll save time when it comes to supporting other languages in the future.

Here are two examples of language-specific semantics for JavaScript/TypeScript:

• The try blocks in which exceptions are untyped, and only one catch is allowed.
• Labels are attached to a specific statement, and you can jump to them only from the break statement nested within that statement. You can also jump to the label using continue if it is inside a loop.

Testing approach

Checking that a CFG is correct is quite an adventure of its own. The first thing that comes to mind is to serialize the graph in Graphviz (or some other way), check it visually, and save it as a reference. Spoiler: that was a trap, and we fell into it. Here’s why it doesn’t work:

• The graph changes constantly during development. You end up manually rewriting the failing tests or burning through AI agents’ tokens.
• It’s very easy to miss a bug in the reference. If people didn’t make mistakes, the static analysis industry wouldn’t exist.
• A neat-looking topology doesn’t guarantee that the graph captures the full semantics of the control flow.

So we changed the approach and wrote a mini-interpreter for our CAT, driven by the CFG. The idea is simple: if our interpreter, after traversing the graph, produces the same result as the JavaScript interpreter, the graph is constructed correctly. We verify this with a simple assertion API, like this:

@Test
void branching() {
    EvaluationAssert.evaluate("branching")
                    .withParam("param", true)
                    .expect("a", 2);

    EvaluationAssert.evaluate("branching")
                    .withParam("param", false)
                    .expect("a", 0);
}

This test runs the interpreter and compares the execution results with the reference, which you can get by running the TypeScript code beforehand:

function branching(param: boolean) {
    let a = 1;
    if (param) {
        a++;
    } else {
        a--;
    }
}

We didn’t have to implement the entire JavaScript specification — a tiny subset was enough. Cutting corners actually worked in our favor: if you don’t clear variables when they go out of scope, you can inspect the state of the code at different points.

Another nice bonus: the minimalist interpreter is a full-fledged proof of concept for graph processing. It can serve both as a reference for using the API and as groundwork for upcoming data-flow analysis.

The result is a working graph builder for JavaScript/TypeScript that constructs each graph in a single AST traversal. It’s quite fast: for React, all graphs are built in a quarter of a second.

What it can catch today

Linear code

The most basic typos, the kind the AST could catch too, come first, of course:

if ( curveLengths[ i ] >= d ) {
    diff = curveLengths[ i ] - d;
    curve = this.curves[ i ];
    var u = 1 - diff / curve.getLength();
    return curve.getPointAt( u );
    break;
}

The PVS-Studio warning: V7039 Unreachable code detected. Control flow never reaches this statement. three.js 29417.

That’s the graph built by the analyzer:

What are merge nodes?

A merge node is an auxiliary node used during graph construction. It makes the graph easier to work with, because nodes with multiple predecessors are cumbersome to handle. The analysis doesn’t use merge nodes (yet).

In the example above, the merge has only one incoming edge instead of two, as in the previous scheme, because the true branch contains a return, which requires an edge to be created straight to the exit node.

The graph shows clearly no path lead to break, so the analyzer marks it as unreachable.

It’s unlikely that this error has any effect, and the unreachable break is probably just redundant. But here's the interesting part: this file is the Three.js library, copied into Juice Shop, and we couldn't find the same error in the current Three.js repository.

By the way, here’s a classic bug involving automatic semicolon insertion (ASI):

function foo() {
    return // asi happens here
        this.bar
}

The analyzer catches it the same way. The inserted ; creates a terminator in the block containing the return and moves this.bar to the next block:

Conditions

Phaser gives us a good example of “defensive programming”:

if (!childA.parentContainer && !childB.parentContainer)
{
    return this.displayList.getIndex(childB)
      - this.displayList.getIndex(childA);
}
else if (childA.parentContainer === childB.parentContainer) {
// more branches ending with return statements here
} else
{
    var listA = childA.getIndexList();
    var listB = childB.getIndexList();
    var len = Math.min(listA.length, listB.length);

    for (var i = 0; i < len; i++)
    {
        var indexA = listA[i];
        var indexB = listB[i];

        if (indexA === indexB)
        {
            continue;
        }
        else
        {
            return indexB - indexA;
        }
    }
    return listB.length - listA.length;
}
//  Technically this shouldn't happen, but ...
// eslint-disable-next-line no-unreachable
return 0;

The PVS-Studio warning: V7039 Unreachable code detected. Control flow never reaches this statement. InputPlugin.js 2981

There were more else-if branches, but I removed them to keep the example short and to the graph small:

If you peruse the comment and look at the code, the programmers’ concern starts making sense: the logic above is complex, merging more than 5 branches, each of which terminates the execution flow. Devs decided to play it safe, not even trusting ESLint. Following its trail, the analyzer saw from the graph’s topology that there is simply no path to return 0.

Loops

As a bonus, we also get the ability to identify loops that run infinitely or, conversely, only once. I found such a case in the already mentioned Three.js:

loop:
for (var pos = 0; pos < limit; pos++) {
    for (; pos < limit; pos++) {                 // <=
        for (var k = 0; k < needleLength; k++) {
            if (haystack[pos + k] !== needle[k]) {
                continue loop;
            }
        }

        return pos;
    }
}

The PVS-Studio warning: V7039 Unreachable code detected. Control flow never reaches this statement. opentype.module.js 6109.

Here is the control flow graph:

The diagnostic rule warns that the increment of the pos variable in the loop is unreachable. Looking at the code, you can easily see that all the branches indeed terminate the second for loop, so it runs only once. The graph confirms this—there is no path to the increment.

This code originally came from OpenType, but the copied dependency was removed at the time of the writing.

Exception handling

Nested try blocks and execution flow interruptions from finally are rare andoften considered a code smell, so I couldn't find any instances in open-source code right away.

Still, this was one of the trickiest cases to handle due to the complexity of the try-catch-finally semantics. The analyzer has to handle several things:

• Check if the try block contains a catch, a finally, or both;
• Track explicit throw statements and also handle where implicit exceptions lead.
• Override the control flow interruption within the finally block when the control flow interruption occurs in try or catch.
• Propagate the control flow interruption that occurs in finally up through the try block.
• Cover many other edge cases and their combinations.

Since I still want to show this case, here’s a synthetic example:

function tryCatchFinallyCase() {
    try {
        try {
            throw new Error("Whoops");
        } finally {
            console.log("inner")
        }
        return true // V7039
    } finally {
        console.log("outer")
    }
    return false; // V7039
}

For this function, the analyzer will construct the following graph:

The diagram clearly shows that the edges themselves carry information about which operation they “remembered” before exiting the function. The analyzer also identifies the unreachable return nodes.

What’s next?

We’ve walked through the errors that the analyzer can now detect thanks to control flow graph support. It has already proven its capabilities, making it fairly straightforward to implement diagnostic rules V7039 (unreachable code) and V7040 (infinite recursion) by the time PVS-Studio 8.00 was released. Beyond adding new diagnostic rules, other opportunities are opening up:

• Extend the CFG construction by applying it to short-circuit expressions.
• Find dead code as well as unreachable code, using conditional constant propagation. Once we have laid the groundwork for the data-flow analysis engine, we can implement taint analysis (tracking tainted data throughout the program).
• Extend the same engine to other kinds of data-flow analysis, such as detecting null dereference, division by zero, and so on.

In short, CAT grows the analyzer wider, and the CFG lets us grow it deeper. The ground for developing the new analyzer is now even more productive.

Wrap-up

That’s the end of the brief overview of the analyzer’s technology. I hope you enjoyed seeing how static analysis works and what kinds of errors control flow analysis can find. If you’ve worked with similar technologies, share your experience in the comments. I’d love to read your stories. The promised article on the inner workings of CAT is still on the way, along with more articles on code quality. Follow us to stay tuned:

• PVS-Studio in X;
• monthly newsletter;
• my personal blog.

How we made JavaScript analyzer understand control flow was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Create is a Minecraft mod that adds shafts, gears, and other mechanical components. You can combine them to build machines powered by rotational force, from a simple windmill to a fully automated cake factory.

The mod is hugely popular: it has more than 206 million downloads on CurseForge alone. That doesn’t even include Modrinth, and the mod keeps getting updates for new versions of the game. I’m pretty sure almost everyone who opened the article has played this mod.

Let’s check the project

Some important info:

• To check the project, I used PVS-Studio static analyzer. The article author is one of its developers.
• You’ll see code examples as you read. Most of them have been shortened to avoid overwhelming the reader. I’ve also put an ellipsis to mark the shortened code: “….”.
• At the time of the check, the latest revision was the 87b3c6a commit. I checked it using the static analyzer.
• All analyzed source files and any conclusions based on other source files, include a permanent link that you can use to find them.
• The article includes only the bugs that the author found interesting (yes, it’s a matter of personal taste). If you want to see the rest, you can always download the analyzer and check the project yourself.

Ctrl + V doesn’t work

The SchematicEditScreen.java(130) file

Let’s take a look at the menu for pasting a schematic. What’s a schematic? A schematic is a part of the game world saved as a separate file. This lets you move your house from one world to another, for example.

public boolean keyPressed(int code, ....) {
  if (isPaste(code)) {
    String coords = minecraft.keyboardHandler.getClipboard();
    if (coords != null && !coords.isEmpty()) {
      coords.replaceAll(" ", "");             // <=
      String[] split = coords.split(",");
      if (split.length == 3) {
        boolean valid = true;
        for (String s : split) {
          try {
            Integer.parseInt(s);
          } catch (NumberFormatException e) {
            valid = false;
          }
        }
        if (valid) {
          xInput.setValue(split[0]);
          yInput.setValue(split[1]);
          zInput.setValue(split[2]);
          return true;
        }
      }
    }
  }
  ....
}

The PVS-Studio warning:

V6010 The return value of function ‘replaceAll’ is required to be utilized. SchematicEditScreen.java 130

The idea is simple: the player copies the coordinates, presses Ctrl + V in a dedicated window, and the fields fill in automatically.

But the replaceAll call marked // <= serves no purpose. Strings in Java are immutable, so the method doesn't modify the original string; it returns a new one instead. The new string is immediately discarded, leaving the spaces instead.

The code then splits the string by commas, leaving a space at the beginning of the second and third elements, and Integer.parseInt(" 67") throws a NumberFormatException. As a result, the fields remain empty.

After opening the menu, I saw the expected behavior:

• -156, 67, 204 doesn't work;
• -156,67,204 works.

The fix fits on a single line. We just add an assignment before the replaceAll operation:

coords = coords.replaceAll(" ", "");

Unnecessary maximum

The ScheduleScreen.java(557) file

for (List<ScheduleWaitCondition> list : entry.conditions) {
  int maxWidth = getConditionColumnWidth(list);
  for (int i = 0; i < list.size(); i++) {
    ScheduleWaitCondition scheduleWaitCondition = list.get(i);
    Math.max(maxWidth, renderInput(....));   // <=
    scheduleWaitCondition.renderSpecialIcon(....);
  }
  AllGuiTextures.SCHEDULE_CONDITION_APPEND.render(
    graphics, 
    xOffset + (maxWidth - 10) / 2,
    29 + list.size() * 18
  );
  xOffset += maxWidth + 10;
}

The PVS-Studio warning:

V6010 The return value of function ‘max’ is required to be utilized. ScheduleScreen.java 557

The analyzer warning clearly explains the error: the result of the Math.max(....) call isn't written anywhere.

I looked through the commit history, expecting to find some traces of refactoring. I thought the developers might have moved the width calculation to a separate method and removed the assignment to maxWidth but left the Math#max call untouched. There was nothing like that, though. The file first appeared on February 1, 2022, in a single 941-line commit, and the Math#max call without an assignment had been there all along. The original initialization of maxWidth with a call to getConditionColumnWidth() was there too.

What would change if the devs added maxWidth = Math.max(....)? Nothing. The column width where the text appears (see the image below) is calculated in advance with some extra room: getConditionColumnWidth() goes through the entire column and takes the maximum width, so no line can extend beyond it. I checked this using the debugger: in every case I was able to test, it returned the same width. So, the code is searching for the maximum of two identical numbers.

The line didn’t break over time, nor was it affected by any refactoring. From day one, it had done nothing — for four years and through several updates to newer Minecraft versions.

I’d suggest removing the unnecessary wrapper and leaving renderInput on its own.

Ignore error handling

The MechanicalCrafterBlockEntity.java(535) file

First of all, let me show you what the mechanical crafter looks like:

Image explanation:

In vanilla Minecraft, players craft items at a crafting table by manually placing ingredients in specific slots. A mechanical crafter does the same thing automatically. You build a grid from several blocks, with each block corresponding to one slot in the recipe, and place the required ingredient in each one. The screenshot shows the recipe for an iron pickaxe: three ingots in the top row and two sticks down the middle.

The arrows on the front indicate the route. The crafters pass items from one to another along the chain until everything reaches the final block. That’s where the recipe gets assembled, and the finished item moves on to a conveyor belt or into a chest.

The whole system runs on rotational power, so it needs a drive connected to the side. In the screenshot, a creative motor powers the grid.

Let’s take a look at a method in its logic:

protected void continueIfAllPrecedingFinished() {
  List<MechanicalCrafterBlockEntity> preceding = 
    RecipeGridHandler.getPrecedingCrafters(this);

  if (preceding == null) { // <=
    ejectWholeGrid();
    return;
  }

  for (MechanicalCrafterBlockEntity blockEntity : preceding)
    if (blockEntity.phase != Phase.WAITING)
      return;
  
  phase = Phase.ASSEMBLING;
  countDown = 1;
}

The PVS-Studio warning:

V6007 Expression ‘preceding == null’ is always false. New returns not-null reference. MechanicalCrafterBlockEntity.java 535

The getPrecedingCrafters method returns the crafters that come earlier in the chain. In other words, the ones that feed items into the current crafter. It can never return null. A list is created at the start, and both method exits return it. Even if the block isn't a crafter, the method returns an empty list:

public static List<MechanicalCrafterBlockEntity> getPrecedingCrafters(
  MechanicalCrafterBlockEntity crafter
) {
  BlockPos pos = crafter.getBlockPos();
  Level world = crafter.getLevel();
  List<MechanicalCrafterBlockEntity> crafters = new ArrayList<>();
  BlockState blockState = crafter.getBlockState();

  if (!isCrafter(blockState))
    return crafters;

  ....
  return crafters;
}

This means the branch with ejectWholeGrid() is unreachable. The preceding list can never be null, but it can be empty, and often is. What if we replace the check with isEmpty() and test it in the game? Let's see what happens.

Before the fix:

After the fix with isEmpty:

The video shows that, before the fix, items entering the loop were passed from one crafter to another indefinitely. That could potentially cause trouble and break someone’s factory :)

However, after the check was replaced with isEmpty(), the loop didn't even have a chance to form. The method determined that there was nowhere else to expect items from, so it ejected them.

However, as soon as I added two more crafters to the chain, the fix stopped working:

Two options are possible here. Either the mechanical crafter needs to detect loops differently, then simply replacing the check with isEmpty() isn't enough. Or this looping behavior isn't a bug at all. In that case, we can just remove the null check.

The logging crash

The TrainRelocationPacket.java(52) file

Here’s the client-server train movement package handler:

public void handle(ServerPlayer sender) {
  Train train = Create.RAILWAYS.trains.get(trainId);
  Entity entity = sender.level().getEntity(entityId);

  String messagePrefix = sender.getName()
      .getString() + " could not relocate Train ";

  if (
    train == null || // <=
    !(entity instanceof CarriageContraptionEntity cce)
  ) {
    Create.LOGGER.warn(messagePrefix + train.id.toString()
        .substring(0, 5) + ": not present on server");
    return;
  }

  if (!train.id.equals(cce.trainId))
    return;

  ....
}

The PVS-Studio warning:

V6008 Potential null dereference of ‘train’. TrainRelocationPacket.java 52

The condition triggers in two cases: either the train can’t be found, or the entity is of the wrong class. The second case is fine: it logs a proper warning. However, in the first case, the code accesses train.id when train is null.

The funny part is that the message we’re trying to log ends with not present on server. The branch was created for a missing train, but it fails because of it.

The packet comes from the client, meaning it chooses the train ID. A modified client build can send requests to transfer nonexistent trains and make the server fill its log with stack traces.

The server won’t crash: Create registers its packets so they execute safely, and even if an exception occurs, it gets logged, while the packet simply goes unhandled.

We can fix this by including the identifier in the package:

messagePrefix + trainId.toString().substring(0, 5)

The two-state theory

The MechanicalMixerBlockEntity.java(238) file

protected List<Recipe<?>> getMatchingRecipes() {
  List<Recipe<?>> matchingRecipes = super.getMatchingRecipes();  
  if (!AllConfigs.server().recipes.allowBrewingInMixer.get())
    return matchingRecipes;

  Optional<BasinBlockEntity> basin = getBasin();
  if (!basin.isPresent())
    return matchingRecipes;

  BasinBlockEntity basinBlockEntity = basin.get();
  if (basin.isEmpty()) // <= 
    return matchingRecipes;

  IItemHandler availableItems = level.getCapability(
  Capabilities.ItemHandler.BLOCK, 
  basinBlockEntity.getBlockPos(), null
  );

  if (availableItems == null)
    return matchingRecipes;

  for (int i = 0; i < availableItems.getSlots(); i++) {
    ....
  }
  
  return matchingRecipes;
}

The PVS-Studio warning:

V6007 Expression ‘basin.isEmpty()’ is always true. MechanicalMixerBlockEntity.java 238

Here, basin.isEmpty() can never return true, so return in this branch is unreachable. Most likely, the developers meant to check basinBlockEntity rather than Optional.

This doesn’t affect gameplay in any way. Further down, the code has other checks that work with the same block, and if the basin is empty, either the loop doesn’t run or availableItems is null.

But a dead if is more dangerous than it looks. It's a safeguard that doesn't really protect against anything. Rewriting the checks below leaves a hole that no one will think to look for because the check is kind of there.

Method contracts must be followed

The Contraption.java(230) file

public static Contraption fromNBT(Level world, CompoundTag nbt, 
                  boolean spawnData) {
  String type = nbt.getString("Type");
  Contraption contraption = ContraptionType.fromType(type);
  contraption.readNBT(world, nbt, spawnData);
  ....
}

Can you see the error? What if we take a look inside ContraptionType#fromType?

/**
 * Lookup the ContraptionType with the given ID, 
 * and create a new Contraption from it if present.
 * If it doesn't exist, returns null.
 */
@Nullable
public static Contraption fromType(String typeId) {
  ContraptionType legacy = AllContraptionTypes.BY_LEGACY_NAME
                        .get(typeId);
  if (legacy != null) {
    return legacy.factory.get();
  }
  ResourceLocation id = ResourceLocation.tryParse(typeId);
  ContraptionType type = CreateBuiltInRegistries.CONTRAPTION_TYPE.get(id);
  return type == null ? null : type.factory.get();
}

Now it’s clear. The method explicitly warns about null twice: with an annotation and a comment. However, the caller code doesn't check anything.

The PVS-Studio warning:

V6008 Potential null dereference of ‘contraption’. Contraption.java 230

It’s easier to break than it seems. The very first line calls nbt.getString("Type"), and if the key doesn't exist, an empty string is returned. This type isn't in the registry either, so the code returns null again.

We can verify this pretty easily by giving ourselves a minecart with a nonexistent contraption type:

/give @p
create:minecart_contraption[create:minecart_contraption_data=
{Type:"create:does_not_exist",InitialOrientation:"north"}]

What is a contraption?

A contraption is a structure that the mod detaches from the world and turns into a single movable object: a platform on a minecart, a piston carrying a load, or a rotating bridge. The blocks inside stop being part of the world and are stored as data belonging to a single entity instead.

The command won’t break anything, and the item will go into the inventory without a problem. But once we put the minecart on the rails, MinecartContraptionItem will try to build a contraption from this data, and that's where we'll get a stack trace with NullPointerException. Minecraft will replace the player's contraption with a vanilla minecart.

We can easily add the check:

Contraption contraption = ContraptionType.fromType(type);
if (contraption == null) {
  Create.LOGGER.warn("Unknown contraption type: {}", type);
  return null;
}

But then null will need to be handled in both code snippets that call it. That raises the question of what to do with a minecart whose contents the mod can no longer understand. Should we leave it as an empty minecart, or simply not load the entity at all? I think it's worth asking the mod developers. They clearly know better than anyone else what to do here.

Interruption

The ServerLagger.java(14) file

public void tick() {
  if (!isLagging || tickTime <= 0)
    return;

  try {
    Thread.sleep(tickTime);
  } catch (InterruptedException e) {
    e.printStackTrace();
  }
}

The PVS-Studio warning:

V6103 Ignored InterruptedException could lead to delayed thread shutdown. ServerLagger.java 14

ServerLagger is a helper class for the killtps start <tickTime> debug command that puts the server to sleep for the specified number of milliseconds on every tick, allowing to see how the mod behaves when the TPS drops. It's available only in debug builds and only to operators (that's what server administrators are called), so there's no need to worry. However, the code is still incorrect, and it's worth explaining why.

When the thread is interrupted, sleep immediately throws an InterruptedException and also clears the interrupt flag. In other words, after catch, it seems like nothing's left: no flag, no exception, just a line in System.err. The method returns control without issue, and the server continues running as if it had never been called.

An interrupt is a request for the entire thread to stop, not just the part where you catch it. By interrupting the thread and doing nothing, you take that request and throw it away. The Javadoc explicitly points this out. One line is enough to pass the interrupt:

} catch (InterruptedException e) {
  Thread.currentThread().interrupt();
}

Conclusion

That’s all for today. I collected all the bugs both in this article and in pull requests for the project’s developers (click, click).

Want to try static analysis too? You can always integrate it into your own project with PVS-Studio. You can download a trial version here. The license is free for open-source projects.

I found some bugs in Create mod and checked them in Minecraft was originally published in PVS-Studio on Medium, where people are continuing the conversation by highlighting and responding to this story.