DEV Community: Unicorn Developer

C++: Write, shorten, optimize

Unicorn Developer — Thu, 23 Jul 2026 14:01:55 +0000

I stumble upon a C++ function that will be a really illustrative example of how refactoring can both shorten and optimize code. Today, we'll need to dust off our human brains in the era of vibe coding and recall what it's like to know what the good is and what the bad is—after all, someone has to do it.

The code snippet below from the vibe-coded project VibeTensor. I like exploring such projects as if I were a naturalist studying a new ecosystem—you can meet with my "field reports" here and there. So, I'm very curious to discover the genesis of new defects and flaws in code. Why? It helps us better understand and describe the challenges code can face in the GenAI era.

One of my discoveries is code bloat that hurts readability and compilers' optimization. The following example showcases it in all its beauty.

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  const std::size_t nd = sizes.size();
  std::vector<int64_t> strides(nd, 0);
  int64_t acc = 1;
  for (std::ptrdiff_t i = static_cast<std::ptrdiff_t>(nd) - 1; i >= 0; --i) {
    strides[static_cast<std::size_t>(i)] = acc;
    const auto sz = sizes[static_cast<std::size_t>(i)];
    acc *= (sz == 0 ? 1 : sz);
  }

  int64_t ne = 1;
  bool any_zero = false;
  for (auto s : sizes) {
    if (s == 0) {
      any_zero = true;
      break;
    }
    ne *= s;
  }
  if (any_zero) {
    ne = 0;
  }
  ....
}

It may seem that code size and performance are not so critical because they're used in tests.

However, the code is duplicated across nine files, and ideally, that shouldn't happen at all, but if code is going to spread like this, it should at least stay compact.

Also, we shouldn't forget that the generated C++ code must be optimized because the C++'s main purpose is to create highly efficient apps. In this case, we have to deal only with the slow test, but in another context, such patterns would significantly downgrade app performance and the negative impact would only grow as more flawed generated code accumulates over time.

Slow C++ code goes against the idea of this programming language. That's why it's still a must-have to enhance the expertise in determining whether the code is well-written and how it can be refined, shortened, or optimized. Advanced knowledge can also help in regenerating code with better prompts.

So, let's practice and do some refactoring. Let's start with this code fragment:

int64_t ne = 1;
bool any_zero = false;
for (auto s : sizes) {
  if (s == 0) {
    any_zero = true;
    break;
  }
  ne *= s;
}
if (any_zero) {
  ne = 0;
}

All the array elements are multiplied. If it encounters 0, the loop terminates to avoid unnecessarily processing the remaining array elements because it'll still set the result to zero.

The any_zero flag resets the variable that stores the product, but we can go easier:

int64_t ne = 1;
for (auto s : sizes) {
  if (s == 0) {
    ne = 0;
    break;
  }
  ne *= s;
}

When we encounter 0, ne will be set to 0 and the loop will end. We have another place for simplification: modern processors perform multiplication operations quickly, so we can do the multiplication first and then check it.

int64_t ne = 1;
for (auto s : sizes) {
  ne *= s;
  if (s == 0) {
    break;
  }
}

The code's functionality hasn't changed, but it's become shorter and, in my opinion, even easier to understand.

If we already know that the array is small or that performance isn't critical (for example, because the function is called infrequently), we could simplify it even further:

int64_t ne = 1;
for (auto s : sizes) {
  ne *= s;
}

Let's not think about that, since further actions make the loop be absorbed by another one.

Now let's go back to the beginning of the function.

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  const std::size_t nd = sizes.size();
  std::vector<int64_t> strides(nd, 0);
  int64_t acc = 1;
  for (std::ptrdiff_t i = static_cast<std::ptrdiff_t>(nd) - 1; i >= 0; --i) {
    strides[static_cast<std::size_t>(i)] = acc;
    const auto sz = sizes[static_cast<std::size_t>(i)];
    acc *= (sz == 0 ? 1 : sz);
  }

The static_cast makes code clunky. The first type casting is needed so that certain compilers or static analyzers don't flag odd arithmetic operations.

std::ptrdiff_t i = static_cast<std::ptrdiff_t>(nd) - 1;

Let's consider what would happen if we removed the static_cast and the input array turned out to be empty:

If the array is empty, then nd = 0;
If we subtract one from an unsigned zero, we get SIZE_MAX, that is, a very large positive unsigned number.
The SIZE_MAX of thesize_t type is implicitly converted to ptrdiff_t and stored in the i variable. It turns out that i = -1 works as intended. But this is exactly where warnings may be issued. We initialize ptrdiff_t with a number that is larger than the range of the largest number it can hold. Before C++20, the result was implementation-defined. Since C++20, the behavior is well-defined.

As a result, it'd be better to leave the first static_cast as is. We can't say the same about the rest. They make no sense at all.

In the vector class, the [] operator takes an argument of the size_type type (typically an alias of size_t). The i variable value will automatically be converted to size_t, and there's nothing unsafe or suspicious about it. The explicit casts only add visual noise, so they're better removed.

for (std::ptrdiff_t i = static_cast<std::ptrdiff_t>(nd) - 1; i >= 0; --i) {
  strides[i] = acc;
  const auto sz = sizes[i];
  acc *= (sz == 0 ? 1 : sz);
}

You've taken the first step. But can we simplify this line even further? Let's see—I'd like to write something like this:

for (auto sz : std::ranges::views::reverse(sizes)) {
  strides[???? i ????] = acc;
  acc *= (sz == 0 ? 1 : sz);
}

You still need the i variable to iterate through the strides array from the end, so we can't eliminate i completely. But we can do something like that:

int64_t acc = 1;
size_t i = nd;
for (auto sz : std::ranges::views::reverse(sizes)) {
  strides[--i] = acc;
  acc *= (sz == 0 ? 1 : sz);
}

To be honest, I don't like that --i has made the code more complicated and forces us to pause and realize why the variable is decremented in the beginning and then is used to access an array element.

Okay, there is less code now, and it's easier to scan through it quickly, so half the work is done. But the code is still ultimately hard to read—it's neither clearer nor intrinsically harder.

Let's take a look at the result.

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  const std::size_t nd = sizes.size();
  std::vector<int64_t> strides(nd, 0);
  int64_t acc = 1;
  size_t i = nd;
  for (auto sz : std::ranges::views::reverse(sizes)) {
    strides[--i] = acc;
    acc *= (sz == 0 ? 1 : sz);
  }

  int64_t ne = 1;

  for (auto s : sizes) {
    ne *= s;
    if (s == 0) {
      break;
    }
  }
  ....
}

Now that there is less code, it becomes clear that the second loop is redundant. In the first loop, we iterate through all the elements. So why not multiply them right away?

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  const std::size_t nd = sizes.size();
  std::vector<int64_t> strides(nd, 0);
  int64_t acc = 1;
  size_t i = nd;
  int64_t ne = 1;
  for (auto sz : std::ranges::views::reverse(sizes)) {
    strides[--i] = acc;
    acc *= (sz == 0 ? 1 : sz);
    ne *= sz;
  }
  ....
}

Oh, it's an absolute beauty. It's not a big deal that we multiply all the elements together, even though one of them might be zero. Microprocessors are multiplying rapidly these days. You could lose more by re-accessing all the elements in the second loop.

What else is left? We don't need to initialize the strides container with zeros. All of its elements will be overwritten anyway.

std::vector<int64_t> strides(nd, 0); // delete the second argument

I think that's all. We can also make one more small change: remove the nd variable. It's not needed here or in the code that follows.

As a result, we have:

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  auto q = sizes.size();
  std::vector<int64_t> strides(q);
  int64_t acc = 1;
  int64_t ne = 1;
  for (auto sz : std::ranges::views::reverse(sizes)) {
    strides[--q] = acc;
    acc *= (sz == 0 ? 1 : sz);
    ne *= sz;
  }
  ....
}

Hooray! We cut the code in half: from 20 lines down to just 9!

What's inside the assembly code?

The function is shorter now, but does that also improve performance? Yes! Let's take a look at the main section of the assembly code for the original function version.

Clang is used with the -O2 option:

.LBB1_7:
        mov     rax, rsi
        mov     qword ptr [rbx + 8*r12 - 16], rsi
        mov     rsi, qword ptr [r13 + 8*r12 - 16]
        cmp     rsi, 1
        adc     rsi, 0
        imul    rsi, rax
        dec     r12
        cmp     r12, 1
        ja      .LBB1_7
        mov     r12d, 1
        cmp     rbp, r13
        je      .LBB1_9
.LBB1_4:
        mov     rax, qword ptr [r13]
        test    rax, rax
        je      .LBB1_5
        imul    r12, rax
        add     r13, 8
        cmp     r13, rbp
        jne     .LBB1_4
        jmp     .LBB1_9

We can see a rather verbose assembly code with two loops. Now let's compare it with the assembly generated for the refactored version.

.LBB1_10:
        mov     rcx, rsi
        mov     rdx, qword ptr [rbp - 8]
        add     rbp, -8
        mov     qword ptr [rax], rsi
        cmp     rdx, 1
        mov     rsi, rdx
        adc     rsi, 0
        imul    rsi, rcx
        imul    r12, rdx
        add     rax, -8
        cmp     rbp, r13
        jne     .LBB1_10

Oh, that's pure beauty. One loop. Compact and efficient. Wow!

To those who aren't very familiar with the assembly language, it might seem strange that there isn't a conditional jump to implement this: sz == 0 ? 1 : sz.

Here's how it works
The value of acc is stored in the RSI register. We'll need a copy of this value later, so it's stored in the RCX register.

mov     rcx, rsi

The RBP register contains the address used to iterate through the elements of the sizes array in reverse order. Here, we load the element into the sz variable (RDX) and shift the iterator by 8 bytes (the size of the int64_t element) to the left.

mov     rdx, qword ptr [rbp - 8]
add     rbp, -8

RSI is acc. Let's put the register in the strides array. RAX holds the element address. The jump to the previous element will be executed below (see add rax, -8).

mov     qword ptr [rax], rsi

Now, we've reached the cherry on top: acc *= (sz == 0 ? 1 : sz) is executed and the RDX register(sz variable) is compared with 1.

cmp     rdx, 1   // CF = is moved when sz - 1

How does it work?

1 is subtracted from RDX. If a jump occurs, the carry flag (CF) is set. This happens only when CF = 1 if RDX is 0.

This is acc = sz. We overwrote the variable's value, but that's okay because we have a copy of it in RCX.

mov     rsi, rdx // acc = sz

If sz was 0, let's change it to 1. To do this, let's add the CF carry flag. If sz is not 0, then the carry flag is 0, and nothing will change. That's how the compiler avoided the conditional jump.

adc     rsi, 0   // acc = acc + 0 + CF

All that's left is to perform two multiplications, decrement RAX, and continue the loop.

imul    rsi, rcx // acc = acc * {ACC copy in RCS register}
imul    r12, rdx // ne = ne * sz
add     rax, -8
cmp     rbp, r13 // Do we reach the beginning of strides?
jne     .LBB1_10 // If no, we'll get goto LBB1_10

Another way

Do we have another way? Yes, we have. I don't know whether I think about it or not. Unfortunately, after finishing my own refactoring, I made the mistake of immediately asking AI for alternative solutions.

DeepSeek suggestions weren't any better, and some were even worse than the original. For example, it optimized one of the code implementations by reversing the array.

// Wrap out strides
std::reverse(strides.begin(), strides.end());

But Claude Opus came up with an unusual implementation. It was noticed that we don't actually need two independent sequences of multiplications.

If all elements of the input array are non-zero, then at the end of the loop, acc == ne. And if even one element was zero, we can simply set ne to zero at the end. We return to the any_zero flag again, but in a smarter way. Using this idea, we can write the following code:

static TensorImpl make_contiguous_tensor(const std::vector<int64_t>& sizes) {
  auto q = sizes.size();
  std::vector<int64_t> strides(q);
  int64_t acc = 1;
  bool any_zero = false;
  for (auto sz : std::ranges::views::reverse(sizes)) {
    strides[--q] = acc;
    acc *= (sz == 0 ? 1 : sz);
    any_zero |= sz == 0;
  }
  const int64_t ne = any_zero ? 0 : acc;
  ....
}

Assembly code

.LBB1_7:
        mov     rdx, rsi
        mov     rsi, qword ptr [r13 - 8]
        add     r13, -8
        mov     qword ptr [rcx], rdx
        test    rsi, rsi
        sete    dil
        cmp     rsi, 1
        adc     rsi, 0
        imul    rsi, rdx
        or      al, dil
        add     rcx, -8
        cmp     r13, rbp
        jne     .LBB1_7
        xor     r13d, r13d
        test    al, 1
        cmove   r13, rsi
        mov     r14, r8

Will code that performs half as many multiplications run faster? My prediction—not necessarily. The processor can perform two unrelated multiplications simultaneously on different pipelines. I'm willing to bet that my version and Claude's version will run at almost the same speed.

Performance measurement

Let's see how these implementations compare in reality. Designing a fair benchmark took a bit of effort. First, I had to ensure the input data couldn't overflow a 64-bit signed integer, since signed overflow is undefined behavior and would invalidate the measurements. Second, to make the contest fair, the test cases alternated between arrays with and without zero elements. Finally, the input arrays had varying lengths.

I'm not claiming that the measurements are rigorous, but they represent a general idea. The speed of the first original algorithm is taken as the baseline. I used Clang with the -O2 and -m64 options.

The original version with two loops: 1.
My version with a single loop: 0.88.
The Claude version with a single multiplication: 0.92.

The refactoring improved performance by about 10% on average. I was actually hoping for a 20–30% speedup, but 10% is still a nice result—especially considering that it came from simplifying the code rather than making it more complicated.

Wrap-up

Let's stop our little refactoring adventure here. Was it worth it?

From the perspective of improving this particular piece of code, I'd say no. Tests are generated. It's not critical that code is longer and slower than it could be.

It doesn't matter whether code is written by a human or generated by AI. One thing remains constant, someone must recognize what bad is and what good is. There must be experts who can spot the difference. Is the code good? Is it bad? Is the code fast? Is it secure?

Some people can accept just the fact that the code works—and who cares what's inside it. In some cases—for example, for building a prototype—this is reasonable. However, those who aren't interested in architecture, optimization, or security most likely simply don't see or understand the whole picture of developing and maintaining large software products. So, I think we'll likely see a lot of drawbacks on this topic.

AI is a powerful tool, but it's not a magic wand. When Claude suggested an alternative version of the algorithm to me, it was a good example of how AI can be used for research and to enhance human capabilities. But it can just as easily cause harm if used carelessly.

If you want to continue improving your skills as a C++ specialist and create reliable, secure software, I suggest you check out these useful e-books and webinars on our website:

E-books & Webinars

Let's make a programming language. AST—Key points

Unicorn Developer — Wed, 22 Jul 2026 12:50:23 +0000

In this part, we continue the development of a toy programming language by introducing the Abstract Syntax Tree (AST), the data structure that represents the hierarchical structure of source code after parsing.

About the speaker

Yuri Minaev is an experienced C++ developer, architect at PVS-Studio, and a recognized voice in the C++ community who has spoken at CppCast, C++ on Sea, and CppCon. Over the course of ten sessions, he'll guide you through each stage of building your own programming language.

The foundation

Each language construct corresponds to an AST node, while collections of nodes, such as function bodies or parameter lists, are represented by dedicated list nodes. Yuri explains the core node types, including literals, identifiers, unary and binary expressions, assignments, function calls, declarations, statements, and error nodes.

Error nodes allow parsing to continue after syntax errors, enabling the compiler to collect multiple errors instead of stopping at the first one. Invalid nodes propagate their state upward so the entire program can be marked invalid before evaluation.

Let's grow our tree!

A central component of the implementation is the AST builder, which owns every created node and manages memory automatically. As the parser recognizes grammar rules, it instructs the builder to create nodes. Terminal nodes are stored in an internal state, while compound nodes consume previously created child nodes from that state and combine them into larger structures until the root node of the program is produced.

Traversing the Tree

The second half of the talk focuses on traversing the AST with a visitor. The visitor performs a depth-first traversal using preview and visit functions. Preview executes when entering a node and can decide whether to traverse its children, while visit runs after returning from them. This design allows specialized visitors to process only the node types they need.

As an example, Yuri demonstrates an AST printer that uses the visitor to produce a tree-like representation of the program structure, concluding with a preview of future topics covering variables, types, semantics, functions, and evaluation.

Want more?

If you want to watch other talks or see the whole episode, follow this link.

You can also sign up for our upcoming webinars, for example: Let's make a programming language. Variables. We hope to see you there!

If you'd like to learn more about PVS-Studio analyzer, check out our website.

See ya!

PVS-Studio brings Unreal Engine support to Team licenses

Unicorn Developer — Mon, 20 Jul 2026 12:58:32 +0000

Good news for Unreal Engine developers: we've made PVS-Studio more accessible! You can now analyze UE projects in PVS-Studio with a Team license, not just an Enterprise license. We'll explain below why we changed our licensing model and what it means for small and mid-sized game studios.

What is PVS-Studio?

In case you haven't heard of us yet: PVS-Studio is a static analyzer for C, C++, C#, and Java code (+ JavaScript/TypeScript and Go in the upcoming August release). PVS-Studio is a tool that automatically checks your project's code for potential errors, security vulnerabilities, and optimization opportunities without executing the code itself.

If you'd like to learn more about the analyzer's capabilities and use cases, check out our overview article.

PVS-Studio is now more accessible to Unreal Engine developers

Game projects continue to grow in both scale and complexity. A modern game can contain millions of code lines, hundreds of modules, and countless interconnected systems. Even experienced teams may miss bugs that slip past the compiler and code review.

At the same time, a large part of the industry consists of indie and AA studios. Despite having smaller budgets and fewer developers, such teams tackle complex engineering challenges and care just as much about delivering high-quality products.

PVS-Studio 7.43, released in June 2026, introduced an important change: Unreal Engine project analysis is now available with the Team license instead of being limited to Enterprise. This makes the tool more affordable for small and mid-sized game studios and lowers the barrier to adopting static analysis as part of their daily development workflow.

Why did we make this change?

Unreal Engine has long been the go-to option for teams of all sizes, from AAA studios and AA developers to indie teams and solo creators. For many of them, the Enterprise license was excessive, especially when working within a tight budget and carefully selecting development tools.

According to the 2026 State of the Game Industry report, Unreal Engine is now the primary engine for the largest percentage of game developers, with approximately 42% of respondents using it as their main engine. It's particularly popular among AA studios, where the engine is used even more broadly than in the AAA segment.

Figure 1—GDC 2026 State of the Game Industry Report: What game engine do you primarily use for game development?

Like larger studios, these teams face technical challenges such as complex game logic, ever-growing codebases, third-party integrations, platform-specific issues, and hard-to-reproduce bugs. The difference is that they usually have fewer resources available for extensive debugging, manual code reviews, and dedicated QA workflows.

QA often takes a back seat while the team focuses on building gameplay features. As a result, bugs negatively impact the player experience and damage the game's reputation right at release. In smaller studios, developers often have to handle testing themselves because the team isn't big enough and the budget may not allow for hiring dedicated QA specialists.

The Team license is designed with such teams in mind. By adding Unreal Engine support at this licensing tier, we've made static analysis more accessible where it can have the greatest impact: in teams where catching bugs early saves time, money, and effort while helping developers stay focused on creating great games.

How bugs affect development pace

The cost of an error

Players pay especially close attention to the quality of a game during the first few days after its launch. If bugs, crashes, or critical failures arise during that period, the team must immediately shift its focus to analyzing feedback, deploying hotfixes, and stabilizing the game. This means investing time and money on work that is rarely part of the intended project plan.

High-profile releases such as Assassin's Creed Unity and Cyberpunk 2077 demonstrate that technical issues at launch can lead to months of post-release fixes. Teams with limited resources may find it even more challenging to recover from a rocky launch.

In reality, the benefits of catching bugs early extend beyond saving money. Understanding and fixing the issue is usually easier when the code is still fresh in the developer's mind. If the bug surfaces much later, the team has to reconstruct the original context, untangle dependencies, and stop working on other projects to investigate it.

Static analysis naturally fits into everyday development workflows, including local development, builds, and CI. It helps developers spot suspicious code before fixes require lengthy investigations, repeated testing, or urgent patches.

If you'd like to learn more, check out our article on how static analysis affects the cost of fixing errors throughout a project's lifecycle.

What does this mean for a team?

Based on discussions within the community, it's clear that most people don't pursue a career in game development to spend their days shipping emergency patches or tracking down typos in legacy code. They'd rather focus on designing gameplay mechanics, building systems, creating content, and making their game better.

The static analyzer doesn't replace developers or make decisions for the team. Its job is much simpler: it highlights potential issues in code and helping teams find bugs earlier with less effort.

For the team, this means a more streamlined workflow with fewer interruptions and more time to focus on tasks that advance the project.

What does PVS-Studio offer for Unreal Engine projects?

Unreal Engine has its own architecture, type system, coding conventions, and internal mechanisms. So, the key to a thorough analysis is considering the engine specifics instead of relying solely on general C++ checks.

We continue to expand Unreal Engine support in PVS-Studio, including in collaboration with Epic Games. It helps us better account for UE-specific behavior, improve our integrations, and respond more quickly to issues developers encounter when using the analyzer with real-world Unreal Engine projects.

This translates into a smoother out-of-the-box experience for teams working with Unreal Engine:

Annotations for Unreal Engine code

PVS-Studio includes built-in annotations for Unreal Engine. They help the analyzer interpret code more accurately, account for engine-specific behavior, and reduce false positives without requiring extensive manual configuration.

UE-specific diagnostic rules

The analyzer also includes diagnostic rules specifically designed for Unreal Engine projects. They help detect issues stemming from UE-specific coding patterns, engine conventions, and the object lifecycle of the engine. Here are a couple of examples:

V1100: Declaring a pointer to a type derived from 'UObject' in a class that is not derived from 'UObject' is dangerous.
V1102: Violation of naming conventions may cause Unreal Header Tool to work incorrectly.

Integration with the Unreal Engine toolchain

Our goal is to support the workflows and tools that Unreal Engine developers already rely on. This way, introducing static analysis won't disrupt an established development process.

Run PVS-Studio in Unreal Build Tool

Starting with Unreal Engine 4.17, you can run PVS-Studio directly through Unreal Build Tool. This makes it easy to integrate the analyzer into your existing build pipeline and use it as part of your regular development workflow.

Support for multiple Unreal Engine versions

PVS-Studio supports both legacy and current Unreal Engine releases. This is especially important for teams that can't immediately migrate to the latest engine version and need to continue developing projects using their current version.

Integration with Unreal Build Accelerator, Horde, and SN-DBS

For large projects and CI pipelines, analysis speed and seamless integration with existing build infrastructure are essential. PVS-Studio is compatible with Unreal Build Accelerator, Horde, and SN-DBS. This streamlines the integration of static analysis into existing distributed build and code check workflows.

A comprehensive set of diagnostic rules for everyday C++ development

In addition to providing diagnostic rules specific to Unreal Engine, PVS-Studio detects a wide range of issues that can affect any C++ codebase. For example, it can identify:

memory and resource management issues: memory leaks (V773), use-after-free bugs (V774), and double resource deallocation (V586);
uses of uninitialized data: in local variables, class members, and constructors (V614, V730, V670);
object lifetime and reference issues: dangling references, incorrect handling of temporary objects, string_view, lambda, and objects after std::move (V758, V1017, V1047, V1030);
logic errors in conditions and expressions: conditions that always evaluate to true or false, suspicious comparisons, and incorrect operators (V547, V517, V709, V564);
copy-paste errors and other human mistakes: duplicated code fragments, variable name typos, and suspicious inconsistencies between similar checks (V778, V722, V1013, V524);
integer overflows, unsafe conversions, and signedness issues (V1028, V1083, V1112, V1029);
issues with loops, indexing, and array bounds (V557, V621, V776).

Fast fixes for issues and false positives

Working effectively with Unreal Engine requires a stable and reliable tool. That's why we focus on both adding new features and refining existing integrations. We're constantly working to fix reported issues, improve compatibility, and reduce the number of false positives.

Our collaboration with Epic Games plays an important role in this effort. It helps us respond more quickly to changes in the Unreal Engine ecosystem and adapt the analyzer to the real-world needs of developers.

To learn more about our collaboration, check out the article on the Epic Games website.

Ready to give it a try?

Starting with PVS-Studio 7.43, you can analyze Unreal Engine projects under the Team license.

If you use Unreal Engine for development and have considered trying PVS-Studio, now's the perfect time to run the analyzer on your project. If you have any questions about integration or configuration, our support team will be happy to help you.

You can get a trial version here.

Stay creative, and we'll be there to help protect your code from bugs, vulnerabilities, and typos with PVS-Studio.

One mistake no one has ever made. Right?

Unicorn Developer — Thu, 16 Jul 2026 14:02:41 +0000

As early as your freshman year of college—or even earlier—you might have realized that writing arr[len(arr)] is a bad idea. Surely, no one could get that wrong, right? We thought the same thing, until we checked 1,000 projects.

A quick explanation of the error, just in case

Any Go developer knows that the built-in len() function takes a value and returns its length based on the value's type.

Let's check the documentation and take a closer look at a function signature:

func len(v Type) int

The built-in len function returns the length of v based on the type of the passed value:

Array: the number of elements in v.
Pointer to array: the number of elements in *v (even if v is nil).
Slice, or map: the number of elements in v; if v is nil, len(v) is zero.
String: the number of bytes in v.
Channel: the number of elements queued (unread) in the channel buffer; if v is nil, len(v) is zero.

Look at this simple example:

func SimpleExample(arr []int) {
  _ = arr[len(arr)]
}

Collection indices always start at 0. So, for a slice of the n length, the valid indices range from 0 to n – 1. Then len(arr) returns n. As a result, accessing arr[len(arr)] always leads to a program panic.

What's V8031, and how did we discover it?

First, a quick note: in case you didn't know, we're developing PVS-Studio, a static analyzer for C, C++, C#, and Java code. The early access program for the new Go and JS/TS analyzers just ended. We're currently preparing them for the release, which is scheduled for August. Around the same time, the early access program for PVS-Studio Atlas—a team solution for managing code analysis results—will launch. Stay tuned for updates.

Now back to V8031. It's a diagnostic rule for the Go analyzer. We didn't expect it to deliver such good results when we were working on it. We even assumed it might not find anything. We thought, "What if this is a made-up error that can be spotted in any review or test?" From our experience, though, we knew there could be dozens of such errors that are easy to spot but often overlooked due to exhaustion, carelessness, or a lack of effort.

Implementing the diagnostic rule was easy: it's built entirely on AST and uses as little of our own code as possible beyond what Go's built-in analysis tools provide. Feel free to create your own diagnostic rules, by the way. You might want to start with our introductory article, "How to create your own Go static analyzer?"

The next step is testing. In our team, it consists of three stages:

Unit testing;
Running a diagnostic rule on our collection of GitHub projects;
Running a diagnostic rule on the 1,000 most popular Go projects (selected by number of stars).

Right now, we'll focus on the third stage. We were surprised by the results as soon as we got them. Let's take a look at them.

The results

In our articles, we usually describe errors and explain possible ways to fix them. We won't do that here since all the code snippets would have the same description as the one at the beginning of the article.

Project No. 1

bfe is a modern load balancer used by Baidu.

type BasicLitList []*BasicLit
....
func (b BasicLitList) End() token.Pos {
  return b[len(b)].End()
}

PVS-Studio warning: V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(b) - 1' instead. ast.go 138

Project No. 2

Ferret is a programmable data extraction and automation tool for developers.

func (vec *Vector) Push(value core.Value) *Vector {
  slice := vec.getCurrentSlice()
  slice[len(slice)] = value

  return vec
}

PVS-Studio warning: V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(slice) - 1' instead. vector.go 28

Project No. 3

fq is a tool, language, and set of decoders for working with binary and text formats.

var blockFns = map[uint64]func(d *decode.D, dc *decodeContext){
  ....
  blockTypeInterfaceDescription: func(d *decode.D, dc *decodeContext) {
    typ := d.FieldU16("link_type", format.LinkTypeMap)
    d.FieldU16("reserved")
    d.FieldU32("snap_len")
    d.FieldArray("options", ....)

  dc.interfaceTypes[len(dc.interfaceTypes)] = int(typ)
  },
  ....
}

PVS-Studio warning: V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(dc.interfaceTypes) - 1' instead. pcapng.go 234

Project No. 4

Incus is a modern container management system and virtual machine manager.

func qemuRawCfgOverride(conf []cfg.Section, confOverride string) (....) {
  ....
  content := &sectionContent{
    comment: sec.Comment,
    entries: entries,
  }

  indexedSection[len(indexedSection)] = content
  orderedSections = append(orderedSections, section{
    name:    sec.Name,
    content: content,
  })
  ....
}

PVS-Studio warning: V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(indexedSection) - 1' instead. driver_qemu_config_override.go 50

We spotted two such errors in this project:

func (f *heartbeatFixture) node() (*state.State, *cluster.Gateway, string) {
  ....
  f.gateways[len(f.gateways)] = gateway
  f.states[gateway] = state
  f.servers[gateway] = server

  return state, gateway, address
}

V8031 Using the call of the 'len' function as index will cause off-by-one error. Consider using 'len(f.gateways) - 1' instead. heartbeat_test.go 253

We've encountered some errors multiple times in other projects. The reason for this was that some Project 1 included some other Project 2 as a dependency. So, it's fair to say that the errors are piling up.

Let's summarize

We wanted to share these exciting results with you. Although unlikely, this error may lurk in your own project. Not long ago, we discussed another interesting error in the article Does the operator ^ represent exponentiation or exclusion?. And to ensure your project's code is clean, you can use PVS-Studio static analyzer.

Happy coding!

History of JavaScript: Browser wars, ECMAScript, Node.js, TypeScript, and React

Unicorn Developer — Thu, 09 Jul 2026 12:44:06 +0000

It only took ten days to develop the language that powers the web. This article tells the story of JavaScript and the tools that helped shape it.

1995. The birth of a legend

The idea for JavaScript was born at Netscape. At the time, web pages consisted almost entirely of HTML, and Netscape wanted to make them more interactive.

The first step in that direction was licensing Java for use in the Netscape browser. However, Java's complexity proved challenging for web designers.

Brendan Eich was then tasked with creating a programming language that wasn't too complex and could be embedded directly into HTML pages. Eventually, Marc Andreessen, co-founder of Netscape Communications, and Bill Joy, co-founder of Sun Microsystems, also contributed to the language development. To meet the deadline for the Netscape browser release, the companies agreed to collaborate on the language.

During its development, the language changed its name several times. For example, the first version Eich created in just ten days was called Mocha. It was then renamed to LiveScript. The final name was chosen because the word Java was already popular and well-known.

JavaScript was first announced shortly before the second beta release of Netscape Navigator. Meanwhile, Netscape announced that 28 leading IT companies planned to incorporate JavaScript into their future products.

JavaScript 1.0 was released in 1996 alongside Netscape Navigator 2.

1997-1999. ECMAScript

In 1996, Microsoft also released JScript as part of Internet Explorer 3, which was an open-source implementation of JavaScript for Windows. By the way, the name was changed to avoid negotiating trademark rights for Java with Sun Microsystems.

To eliminate browser incompatibilities caused by different implementations, Netscape handed the JavaScript specification over to the ECMA international organization.

So, the ECMA-262 specification was created. The language got the name ECMAScript because JavaScript was already trademarked. Around the same time, the TC39 technical committee was formed, bringing together representatives from Netscape, Microsoft, Sun Microsystems, and other companies. It still exists today, continuing to define the evolution of ECMAScript.

The ECMAScript 2 specification was released in September 1998. Although it didn't introduce any new features, it laid the groundwork for all future changes.

ECMAScript 3 was released in 1999, introducing several new language capabilities, including regular expressions, exception handling, the switch-case statement, and the do-while loop variant.

2001. The end of the first browser war

The first major rivalry among web browser companies began in 1995.

At the time, Netscape Navigator was the most well-known browser because it was available for free non-commercial use. However, as part of the Windows 95 Plus! package, Microsoft released Internet Explorer 1.0.

Just three months later, Internet Explorer 2.0 became available for free download. All Windows users, including commercial organizations, could use the browser for free, which was its key advantage over Netscape Navigator.

From that point on, every Netscape Navigator and Internet Explorer update was an attempt to outdo the competition. In 1996, Internet Explorer began seriously challenging Netscape's browser when it became the first to offer commercial support for Cascading Style Sheets (CSS).

The browser wars involved more than just the companies behind the browsers. Web designers at the time actively placed badges on their websites saying things like "Best viewed in Netscape" or "Best viewed in Internet Explorer." These badges usually linked to the corresponding browser download page and meant that the site had only been tested in one of them. In response, supporters of the open web launched the "Viewable with Any Browser" campaign.

In the end, Microsoft won the battle, securing over 90% of the global market. This was primarily due to the widespread adoption of Windows, which came preinstalled with Internet Explorer as the default browser.

Back in 1998, when defeat became inevitable, Netscape released the source code of its browser. This decision would later play a role in future browser wars. In 2003, AOL, which owned Netscape by that time, finally disbanded the development team.

Meanwhile, Microsoft faced a major lawsuit from the U.S. Department of Justice for violating antitrust laws. The court ruled that the company held a monopoly, requiring it to allow computer manufacturers and users to remove Internet Explorer access icons and install different browsers without altering the Windows interface.

That same year: the first JSON message

The first message in JSON format was sent in April 2001 from a computer in a garage in the San Francisco Bay Area.

Douglas Crockford and Chip Morningstar, co-founders of the State Software technology consulting company, were already trying to build AJAX applications even before the term AJAX was first coined.

The message looked like this:

html<html><head><script>
    document.domain = 'fudco.com';
    parent.session.receive(
        { to: "session", do: "test",
          text: "Hello world" }
    )
</script></head></html>

Only a small part of it resembles the JSON we know today. The message itself is an HTML document containing JavaScript code.

The format was originally supposed to be called JavaScript Markup Language (JSML), but that acronym was already taken by Java Speech Markup Language, so it was renamed to the JavaScript Object Notation we know today.

The authors realized they had developed a versatile format, but customers were reluctant to use an unproven technology without specifications.

This prompted Crockford to purchase the JSON.org domain in 2002, where he published the JSON grammar and a parser implementation.

2004. Google invents AJAX

On April 1, 2004, Google launched Gmail, marking the first large-scale showcase of AJAX. The service loaded emails, updated the interface, and displayed search suggestions without reloading the page, which was a true breakthrough at the time. Paul Buchheit, project creator and one of Google's first employees, used XMLHttpRequest to make the browser experience feel like a desktop application.

Interestingly, the term AJAX appeared a little later. In February 2005, Jesse James Garrett introduced it in his article "Ajax: A New Approach to Web Applications."

Asynchronous JavaScript and XML (AJAX) is an approach to web application development that enables websites to exchange data with a server in the background without fully reloading the page.

AJAX marked the beginning of a new era in web applications and frameworks. It also kicked off Web 2.0, which transformed internet users from passive readers into active content creators.

2006. jQuery

John Resig created jQuery at BarCamp NYC in January 2006. Its key sources of inspiration included Dean Edwards' CSSQuery library and other community projects from that time.

The library was designed to streamline common tasks like DOM traversal, event handling, and AJAX.

jQuery fixed many issues caused by browser incompatibilities, attracting developers with its well-documented and concise API.

As of August 2022, 77% of the 10 million most popular websites used jQuery. On average, jQuery was used three to four times more often than any other JavaScript library, according to web analytics.

2007. Apple reinvents mobile web

When the first iPhones hit the market in 2007, they didn't support Flash, which was the top technology for interactive web content at the time. Flash powered videos, animations, and browser games. Instead of actual content, users saw empty rectangles on websites opened in mobile Safari.

Critics pointed out the obvious contradiction that without Flash, Apple's promotion of Safari as a "full-featured browser" was an exaggeration. Seizing the opportunity, Android added Flash support in version 2.2, presenting it as a key advantage over the iPhone.

In April 2010, Steve Jobs published an open letter titled "Thoughts on Flash." He explained why Flash would never appear on Apple devices: a proprietary technology developed in the mouse-driven era was incompatible with touchscreen interfaces. Flash used too much power and wasn't compatible with hardware acceleration on mobile chips. According to Jobs, the future belonged to open-source standards: HTML5, CSS, and JavaScript.

The market ruled in Apple's favor. The iPhone and iPad quickly gained market share, and web developers had to rewrite websites without Flash while also solving mobile adaptation issues.

In November 2011, Adobe ceased development of Flash for mobile devices and announced the end of the desktop version in 2017. Flash officially ceased to exist on December 31, 2020.

JavaScript was the biggest beneficiary of this story. Open-source standards filled the void left by Flash, with JS becoming their main driving force.

2008. Google Chrome

For six years, Google CEO Eric Schmidt opposed the development of the company's own web browser. He had several reasons for doing so, but the main one was that he didn't want to drag the company into another browser war.

However, the company's co-founders, Sergey Brin and Larry Page, hired several Mozilla Firefox developers and created a demo version of Chrome. Schmidt later admitted, "It was so good that it essentially forced me to change my mind."

On September 2, 2008, Google released the first beta version of Chrome. Thanks to its new V8 JavaScript engine, the browser was built around performance from the start.

Google's engine was revolutionary. Open source from day one, it influenced the development of other tools, most notably Node.js.

The release of Google Chrome marked an important milestone in the second browser war.

That same year: ECMAScript 4 gets canceled

Development of the new language version began in 2000 and continued through 2008; the creators envisioned it as a complete overhaul of JavaScript. However, it caused a real crisis within TC39.

The committee split into two groups: supporters, including Adobe, Mozilla, Opera, and Google, and opponents, including Microsoft and Yahoo. The first group wanted large-scale changes, while the second considered ES4 too complex and incompatible with existing code.

The situation got so bad that Microsoft effectively sabotaged the process by blocking the adoption of proposed changes.

In the end, ECMAScript 4 was canceled. Instead, a more conservative ECMAScript 5 was released later, while some of the biggest changes returned with the release of ES6. Adobe developers adopted many of those ideas, which became part of ActionScript 3.

Following this, TC39 introduced a staged process where each feature follows its own path from proposal to inclusion in the standard. This approach paved the way for the annual release of new ECMAScript versions in the future.

2009. Node.js

The first version of an open-source, cross-platform JavaScript runtime environment outside of a browser was released in May 2009, approximately 13 years after Netscape introduced the LiveWire Pro Web server environment.

Ryan Dahl, the creator of Node.js, criticized the Apache HTTP Server for its limited capacity to handle large numbers of simultaneous connections and the sequential programming approach dominant in the industry.

Node.js overcame these challenges by combining Google's V8 engine, an event loop, and a low-level I/O API.

Node.js was first presented on November 8, 2009, at JSConf. In early 2010, npm, a package manager for the Node.js environment that allows developers to publish and share packages, was introduced.

The same year: ECMAScript 5

Released in 2009, ECMAScript 5 was the first major update to the language since ES3. It introduced many features that have become essential to JavaScript.

This version added the use strict directive. It helped identify errors that engines previously ignored. For example, creating a variable without first declaring it started throwing a ReferenceError.

It also added many features for working with strings, arrays, objects, JSON, and dates.

It's difficult to imagine modern code without features like Array.forEach, JSON.stringify, and Date.now, all of which appeared in this version of the language.

That same year: Oracle acquires Sun Microsystems

In April 2009, Oracle announced its acquisition of Sun Microsystems, with the deal closing in January 2010. Along with Sun, Oracle also acquired the JavaScript trademark.

The acquisition of the trademark by the corporation resulted in several unusual situations. For example, the Rust for JavaScript Developers community received a letter demanding that they stop using the word "JavaScript" in their name. When renewing the trademark in 2019, Oracle submitted a screenshot of the Node.js website to the USPTO as proof of use, as if claiming ownership rights over any JavaScript projects.

In 2022, this situation led Ryan Dahl, the creator of Node.js and Deno, to publicly ask Oracle to give up the trademark. In 2024, an open letter was released and signed by over 27,000 developers, including Brendan Eich, the creator of JavaScript.

The Deno team filed a petition with the USPTO to cancel the trademark in November of the same year. The case is still ongoing.

Read our article on the history of Java to learn more about how Sun Microsystems was acquired by Oracle.

2012. TypeScript

TypeScript, a language that added static typing to JavaScript, was released in October 2012. The project aimed to streamline the development and maintenance of large-scale JavaScript applications. Anders Hejlsberg, the creator of Turbo Pascal and C#, started developing it in 2010 at Microsoft.

Over the years, TypeScript has influenced the entire ecosystem.

Many TypeScript features appeared before they became part of the ECMAScript specification, including optional chaining (?.), nullish coalescing (??), and others.

Also, strong typing, once considered unnecessary in the JavaScript world, has become the norm. Nowadays, many libraries, both large and small, ship with .d.ts declaration files.

2013. React

React is a library for building UIs. It was first introduced at the JSConf US conference in May 2013.

Development of React began at Facebook in 2010: Jordan Walke created an internal prototype called FaxJS for the news feed. By 2011, React was already in use within the company. The community response was skeptical, with people asking, "How can you mix HTML and JavaScript?"

However, React changed the way developers build interfaces. The component-based model, Virtual DOM, and the one-way data flow have become the new industry standard.

Vue.js, released in 2014, took direct inspiration from React's ideas. Starting with version 2, Angular also switched to a component-based architecture. These approaches have now become the standard.

React Native was released in 2015, enabling developers to build mobile applications using React and paving the way for JavaScript in mobile development.

The Hooks API, introduced in React in 2019, replaced class components and popularized a functional approach to writing code across the JavaScript ecosystem.

The same year: Electron

The framework started as an internal GitHub tool for the Atom text editor, which entered public beta in April 2014. It combines Node.js and Chromium, enabling developers to reuse web code with minimal changes while running it in a controlled browser environment that provides native application privileges.

The technology's potential was quickly recognized, prompting the renaming of Atom Shell to Electron in April 2015. Slack was among the first major adopters, transforming its web client into a full desktop application. Many other products soon followed.

Electron revolutionized desktop application development by making it accessible to the web development community. In the past, building cross-platform applications required extensive knowledge of native technologies. Electron allowed developers to create them using only HTML, CSS, and JavaScript.

2014. Webpack

In 2012, Webpack was released as an open-source JavaScript module bundler. It takes dependencies as input and builds a dependency graph, enabling developers to take a modular approach to web application development. This allowed them to import almost anything to client-side code and, over time, became the foundation of the build process for React, Angular, Vue, and many other frameworks.

The foundation laid by Webpack later gave rise to modern build tools, including Rollup, Vite, and ESBuild.

2015. ECMAScript 6

The new language standard, released in 2015, was the largest update in JavaScript's history. In many ways, JavaScript split into two eras: before and after ES6.

The new version introduced let and const as replacements for var, bringing block scope and eliminating many classic hoisting-related bugs. It also brought arrow functions, which made code more concise and solved common issues with the this context. ES6 also added classes, modules, destructuring, and the spread and rest operators.

ES6 introduced Promise as JavaScript's native solution to the callback hell problem. ES8 later built on that foundation with async/await.

Many practices that are now considered standard in modern JavaScript originated with ES6.

That same year: the end of the second browser war

The second browser war lasted much longer than the first one, and it was on a completely different scale. While the first one was a showdown between Netscape and Microsoft, the second one was a battle of everyone against everyone else.

By 2015, Internet Explorer still held around 80% of the market. Microsoft had grown complacent, causing the browser to stop evolving. Users noticed the stagnation and started switching to other options.

Mozilla Firefox and Opera were the first to capitalize on the situation. Firefox launched in 2004 and immediately offered features Internet Explorer lacked: tabbed browsing, extensions, and better performance. The "ghost" of Netscape had returned for a rematch.

Microsoft responded too late. After five years of stagnation, Internet Explorer 7 was released in October 2006. Microsoft even allowed users with pirated Windows copies to install the new version, but that didn't stop them from leaving. Internet Explorer continued to lose market share quickly.

In 2008, Google Chrome entered the race and permanently shifted the balance of power. Its fast V8 engine, minimalist interface, and aggressive promotion through Google's services all contributed to its success. By the early 2010s, Chrome had overtaken every competitor.

IE lingered on for a few more years until Microsoft released Edge in 2015. Internet Explorer was officially discontinued in 2022.

Chrome has become the web's most popular browser.

2016. Visual Studio Code

Visual Studio Code, a code editor created by Microsoft, was first introduced on April 29, 2015, at the Build conference.

Microsoft developed it during a period of major change in the web development field, when many developers were switching to lightweight editors like Sublime Text and Atom. At the time, Microsoft was still closely associated with the heavyweight Visual Studio IDE. VS Code was built on Electron and has been open source and cross-platform since day one.

The community initially reacted with caution. Many doubted Microsoft's ability to build a tool that would appeal to everyone.

However, VS Code redefined what a code editor could be. Its powerful Extension API and built-in debugger combined with a lightweight user experience proved to be exactly what the market had been missing.

Language Server Protocol was one of the important byproducts. The VS Code team proposed the standard for language integration, which quickly gained adoption across the industry in editors such as Vim, Emacs, and Eclipse. Stack Overflow's developer survey ranked VS Code as the most popular development tool in 2018, and it has held that position ever since.

VS Code was especially important for the JavaScript ecosystem because it shipped with built-in support for JavaScript and TypeScript from the beginning.

By the way, we're developing a Visual Studio Code extension that makes it possible to work with PVS-Studio directly from within the editor. You can learn more about it in the documentation.

2017. WebAssembly

WebAssembly is a binary instruction format for a stack-based virtual machine that became a W3C web standard in 2019. It emerged after years of struggling against JavaScript's performance limits.

Back in 2013, Mozilla introduced asm.js, a strict subset of JavaScript with explicit type annotations that browsers could compile ahead of time. A live demonstration of Unreal Engine 4 running directly in Firefox proved the concept was viable and made a strong impression. However, asm.js was cumbersome, and only one browser supported it.

In 2015, Mozilla, Google, Microsoft, and Apple came together to develop a solution. They all faced the same challenge: JavaScript engines had reached an architectural limit that compiler optimizations alone couldn't overcome.

The MVP was released in early 2017 and appeared in all four major browsers almost simultaneously, which was a level of coordinated rollout the web had never seen before. For compute-intensive workloads, WebAssembly achieved 60–80% of native performance.

Its arrival opened up new possibilities that were previously impossible in web development. For example, Figma rebuilt its rendering engine using C++ and converted it to Wasm, enabling its browser-based editor to perform like a native application. Adobe Photoshop also made its way to the browser, while Unity and Unreal Engine got official Wasm export support.

Although WebAssembly proved invaluable for workloads where JavaScript struggled, it never fully replaced JavaScript—that was never the goal. Instead, JavaScript became the glue that connects Wasm modules to the DOM and browser APIs.

2018. Deno

In 2018, Ryan Dahl, the creator of Node.js, gave a talk at JSConf EU in Berlin titled "10 Things I Regret About Node.js." He outlined what he considered to be the biggest design flaws of Node.js, including its module system, unrestricted access to the network and file system, and so on.

He concluded the talk by announcing Deno (an anagram of Node—Ed.), a new JavaScript runtime that addresses those issues.

For example, instead of granting unrestricted access to the file system and network, Deno introduced permission flags such as --allow-write and --allow-net. Rather than relying on an ever-growing node_modules directory and package.json, it adopted URL-based imports similar to the way external JavaScript files are included in an HTML page.

The first stable version of Deno was released in 2020. In 2021, the project joined TC39. Although Deno differs from Node.js in many ways, its developers remain committed to the JavaScript standard.

Deno 2.0, released in 2024, maintained the original's simplicity while adding compatibility with Node.js and npm.

2020. Vite

In 2020, Evan You, the creator of Vue.js, made a surprisingly obvious point that had been overlooked by everyone: modern browsers already support native ES modules. This meant developers no longer had to bundle code during development. The browser could resolve the required modules on its own.

This idea led to the creation of Vite (French for "fast" — Ed.). Unlike traditional tools, Vite's development server didn't waste time bundling the entire project at startup. Instead, it sent source files directly to the browser like ES modules do, while using esbuild, a Go-based bundler, to pre-bundle dependencies from node_modules. As a result, the time required to initiate these large projects was reduced to mere seconds. When a single file changed, the browser no longer had to reload the entire project; it only needed to reload the modified module.

The first release focused exclusively on Vue, but in February 2021 Vite 2.0 arrived as a completely redesigned, framework-agnostic tool.

Vite played a major role in the decline of Create React App, the longstanding standard for building React projects.

The same ecosystem also gave rise to Vitest, a test runner that uses the same configuration as the build system, allowing developers to avoid duplicating settings for Jest. Vite redefined expectations for development speed in the JavaScript ecosystem, pushing competing tools to match its performance.

By the mid-2020s, Vite had become one of the world's most downloaded npm packages. In March 2026, Vite 8 was released with Rolldown as its sole bundler, replacing the previous esbuild + Rollup combination. Rolldown, written in Rust, enabled application builds that were dozens of times faster.

2022. React on the server

In December 2020, the React team published an RFC titled "Zero-Bundle-Size React Server Components." The idea was simple: what if some components never reached the browser at all? They would run on the server, issue the final output, and then disappear. No client-side re-rendering. No JavaScript added to the bundle.

The proposal addressed a very real problem: large dependencies ended up in users' browsers simply because components imported them. Also, it required a lot of requests: we first send JavaScript, which then fetches the necessary data.

For two years, React Server Components remained an experimental feature. They required a dedicated streaming server and worked only within a supporting framework rather than in React itself. Wider adoption began in October 2022 when the beta version of the App Router was introduced with Next.js 13. In May 2023, version 13.4 was declared stable. Server Actions came alongside it. These are functions marked with the use server directive that are called from the client but executed on the server.

From that point on, a single React project contained two distinct worlds, each with a different execution model. These worlds were separated by the use client and use server directives.

The impact extended far beyond React. Solid.js, Qwik, and Svelte all embraced the idea of sending less JavaScript to the client. Qwik built its entire resumability model around this concept. Instead of rerunning all the necessary JavaScript to rebuild a page, the browser resumes execution from where the server left off.

React 19, released in December 2024, officially added Server Actions to the public API. However, most developers still have to choose between the traditional approach and this newer model.

2026. PVS-Studio analyzer for JavaScript and TypeScript

On April 6, 2026, PVS-Studio launched an Early Access Program (EAP) for its new analyzers. For many years, PVS-Studio has helped developers catch bugs and vulnerabilities in C, C++, C#, and Java projects. Now it's JavaScript's and TypeScript's turn.

The initial release included 20 diagnostic rules, typo and logic error detection, a CLI version, and a plugin for WebStorm. TypeScript support and a VS Code extension followed in May.

The EAP also introduced a new analyzer for Go.

The new analyzers are scheduled for full release in August 2026, alongside PVS-Studio 8.00.

Conclusion

This is where our journey through the history of JavaScript comes to an end. It has been an eventful one, as JavaScript's story is deeply intertwined with the evolution of the web itself.

This article reflects the author's perspective on the history of JavaScript and may not include every milestone you consider significant. If you think something important is missing, please add it in the comments! :)

If you're interested in the history of other programming languages, check out our series of articles on the topic:

See ya soon!

Let’s make a programming language. Variables

Unicorn Developer — Wed, 08 Jul 2026 12:44:33 +0000

We continue building our own programming language from scratch. In this session, 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 webinar, 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 webinar is designed for developers who want to understand how programming languages work under the hood - not just how to use them.

Register to join the session. All registered participants will receive the recording of this webinar, along with recordings of all previous webinars in the series, after the webinar has concluded.

If you missed any of the previous sessions, don't worry. All registered participants get access to the recordings. You can also catch up on YouTube or the PVS-Studio website.

First talk: Let's make a programming language. Intro

Second talk: Let's make a programming language. Grammars

Third talk: Let's make a programming language. Lexer

Fourth talk: Let's make a programming language. Parser

Fifth talk: Let’s make a programming language. AST

Register now to join us live, ask your questions, and get the most out of the session. Don't miss the chance to build your own language alongside an experienced developer.

Join us on July 23, 1:00 PM UTC+1!

P.S. Don't forget to check your inbox and confirm your registration!

Inside BotSharp: Finding bugs in the .NET AI platform's code

Unicorn Developer — Tue, 07 Jul 2026 14:21:32 +0000

C# has a reputation as a language for enterprise development but not for machine learning. BotSharp pushes back on that idea with a powerful AI platform built on .NET. We'll walk through the project and the bugs we found in its source code.

Foreword

Python has long dominated machine learning, while C# made its name in enterprise systems, web development, and game development. That's starting to shift. Tools like ML.NET and Microsoft Agent Framework show that .NET can hold its own in AI development too. BotSharp is one of these tools, and it's what this article is about. Mostly, though, we'll be digging into the bugs we found in its source code using the PVS-Studio static analyzer. Let's get started.

A word about the project

BotSharp is an open source framework written in C#. It's built for creating single-agent and multi-agent systems, where one or more AI models drive the decision-making. These models can process and generate multimedia data, and they can act by calling the tools they're given.

So how does BotSharp differ from Semantic Kernel? Both currently solve similar problems, offering components for building LLM-powered agent systems. What sets BotSharp apart is a higher level of abstraction and built-in infrastructure for managing agents and dialogs, which makes it faster to deploy typical agent-based solutions.

Picture 1 — The BotSharp web interface, provided for visualizing agent-based systems

You can find more on BotSharp in the framework's documentation. For now, though, let's get to the interesting part, the bugs we found in its code.

Error review

PVS-Studio found the bugs covered below in the project's version 5.2, the latest one available as of this writing.

PVS-Studio is a static analysis tool for C#, C, C++, and Java code, built to catch bugs and potential vulnerabilities. Support for Go, JavaScript, and TypeScript is on the way too, and you can sign up now to test those. For more on PVS-Studio, check out the official website.

Unused parameter

public class SettingService : ISettingService
{
  ....
  private readonly ILogger _logger;

  public SettingService(IServiceProvider services,
                        IConfiguration config,
                        ILogger<SettingService> logger)
  {
    _services = services;
     _config = config;
  }
  ....
}

The PVS-Studio warning: V3117. Constructor parameter 'logger' is not used. SettingService.cs 15

Just a sloppy typo: the logger parameter gets passed into the constructor, but nobody assigns it to the matching _logger field. Nothing breaks so far, simply because that the _logger field isn't used anywhere yet. But it's still a trap waiting to be triggered.

Sooner or later someone may want to add logging. They'll spot the field already sitting there, write the usual logging call, and the code will compile without any complaints. Then the first call in prod throws a NullReferenceException out of nowhere. Landmines like this are exactly the kind of thing you don't want to find later.

Missing case in a switch statement

public async Task UpdateAgentTask(....)
{
  ....
  switch (field)
  {
    case AgentTaskField.Name:
      metaData.Name = task.Name;
      break;

    case AgentTaskField.Description:
      metaData.Description = task.Description;
      break;

    case AgentTaskField.Enabled:
      metaData.Enabled = task.Enabled;
      break;

    case AgentTaskField.Content:
      content = task.Content;
      break;

    case AgentTaskField.All:
      metaData.Name = task.Name;
      metaData.Description = task.Description;
      metaData.Enabled = task.Enabled;
      content = task.Content;
      break;
  }
  ....
}

The PVS-Studio warning: V3002. The switch statement does not cover all values of the 'AgentTaskField' enum: Status. FileRepository.AgentTask.cs 234

This switch statement updates the metaData properties based on the flag it receives. Nearly every value in the AgentTaskField enum shows up here, only Status got left out.

Because of this gap, the app misbehaves in two different scenarios. If there's an explicit request to update Status, the switch just ignores it and metaData stays unchanged. The case AgentTaskField.All block has a problem too: it's supposed to overwrite every metadata property with task properties, but since Status got left out, that block doesn't fully do what it's supposed to.

It's a good illustration of how extending an enum without checking every switch statement that depends on it can quietly introduce hidden bugs.

Losing a parameter's value

public async Task<FunctionCallFromLlm> GetNextInstruction(
  ...., 
  List<RoleDialogModel> dialogs)
{
  ....
  dialogs = new List<RoleDialogModel>
  {
    new RoleDialogModel(AgentRole.User, next)
    {
      FunctionName = nameof(HFReasoner),
      MessageId = messageId
    }
  };

  var response = await completion.GetChatCompletions(router, dialogs);
  ....
}

The PVS-Studio warning: V3061. Parameter 'dialogs' is always rewritten in method body before being used. HFReasoner.cs 45

The GetNextInstruction method takes a dialogs collection as a parameter, but instead of adding to it, the method completely replaces the collection with a new, empty template.

The parameter most likely stories some conversation context needed to generate a relevant response. Overwriting the variable wipes that context clean right before the request goes to GetChatCompletions, which can noticeably hurt the quality of the response.

The fix is straightforward. Add the new data with Add or, if necessary, leave the dialogs collection untouched, or build a new collection based on dialogs with the extra element added in.

A copy-pasted condition

public string Make_Payment(
  [Description("order number"), Required] string order_number,
  [Description("total amount"), Required] int total_amount)
{
  if (order_number is null)
  {
    throw new McpException("Missing required argument 'order_number'");
  }
  if (order_number is null)
  {
    throw new McpException("Missing required argument 'total_amount'");
  }
}

The PVS-Studio warning: V3021. There are two 'if' statements with identical conditional expressions. The first 'if' statement contains method return. This means that the second 'if' statement is senseless MakePaymentTool.cs 11

This one comes down to careless copying. The method is meant to check two required parameters, but since both if conditions are identical, order_number gets validated twice, while the second argument never gets checked at all.

The exception text in the second block gives away the original intent, it was supposed to check total_amount. Bugs like this slip right past a quick read, but static analysis catches them immediately.

A misunderstanding of operator precedence

private async Task<List<RoleDialogModel>> OnResponsedDone(....)
{
  ....
  new TokenStatsModel
  {
    ....
    TextInputTokens =  inputTokenDetails?
                      .TextTokens ?? 0 -  inputTokenDetails?
                                         .CachedTokenDetails?
                                         .TextTokens ?? 0,
    ....

    AudioInputTokens =  inputTokenDetails?
                       .AudioTokens ?? 0 -  inputTokenDetails?
                                           .CachedTokenDetails?
                                           .AudioTokens ?? 0,

    ....
  }
  ....
}

The PVS-Studio warning:

V3123. Perhaps the '??' operator works in a different way than it was expected. Its priority is lower than priority of other operators in its left part. RealTimeCompletionProvider.cs 542

V3123. Perhaps the '??' operator works in a different way than it was expected. Its priority is lower than priority of other operators in its left part. RealTimeCompletionProvider.cs 544

This code reads as perfectly logical to a human, but the compiler sees it differently.

The developer attempted to calculate a difference, with each operand guarded against null by the ?? operator. But the subtraction operator - has a higher precedence than the ?? null-coalescing operator, so instead of the intended (A ?? 0) - (B ?? 0) what actually gets evaluated is A ?? ((0 - B) ?? 0).

To get the intended behavior, the expressions around ?? need to be explicitly wrapped in parentheses:

 (inputTokenDetails?.TextTokens ?? 0) - ( inputTokenDetails?
                                         .CachedTokenDetails?
                                         .TextTokens ?? 0)

Potential null dereference

Issue 1

public async Task<RoleDialogModel> GetChatCompletions(....)
{
  ....
  var toolcall = response.choices.FirstOrDefault()?
                         .message
                         .tool_calls.FirstOrDefault();

  responseMessage = new RoleDialogModel(
    AgentRole.Function, JsonSerializer.Serialize(toolcall.function)
  )
  ....
}

The PVS-Studio warning: V3146. Possible null dereference of 'toolcall'. The 'FirstOrDefault' can return default null value. ChatCompletionProvider.cs 62

Here, the toolcall variable gets its value from a call chain that uses the FirstOrDefault method twice.

The developer took every precaution in that chain, so if either collection turns out empty, toolcall ends up as null without throwing anything.

The problem shows up right after, inside JsonSerializer.Serialize, where the variable gets dereferenced with no check beforehand. Sooner or later that throws a NullReferenceException.

Issue 2

public async Task<BrowserActionResult> InputUserText(....)
{
  ....
  locator = Locator(actionParams.ContextId, htmlElementContextOut);
  count = await locator.CountAsync();
  ....
}

The PVS-Studio warning: V3080. Possible null dereference. Consider inspecting 'locator'. PlaywrightWebDriver.InputUserText.cs 46

The analyzer flags another potential null dereference, this time in locator.CountAsync().

The declaration of the Locator method explains why:

private ILocator? Locator(....)
{
  ....
  else if (!string.IsNullOrEmpty(context.ElementName))
  {
    ....
    if (count == 0)
    {
      _logger.LogError(....);
      return null;
    }
    else if (count > 1)
    {
      _logger.LogError(....);
      return null;
    }
  }
  else
  {
    if (context.Index < 0)
    {
       _logger.LogError(....);
       return null;
     }
     ....
  }

  return element;
}

There are three separate paths where this method returns null. Yet in the code the analyzer points to, that return value never gets checked.

Issue 3

public async Task<RoutableAgent[]> GetRoutableAgents(List<string> profiles)
{
  ....
  if (routableAgents.Length > 0 && profiles.Count > 0)
  {
    ....
  }
  else if (profiles == null || profiles.Count == 0)
  {
    ....
  }
  ....
}

The PVS-Studio warning: V3095. The 'profiles' object was used before it was verified against null. Check lines: 131, 137. RoutingService.cs 131

This one comes down to a validation order problem. The developer planned for profiles possibly being uninitialized and added a check for it in the else if block. But that check comes too late, the if statement above it already calls profiles.Count. Swapping the two blocks fixes the logic.

Conclusion

I hope this tour through the BotSharp source code was useful, and hopefully a bit entertaining too. Defects like these, an unclear operator precedence, a forgotten case in a switch statement, a lost argument value, blend right into large codebases. Finding them by hand in a massive project is a lot harder than it sounds, and that's exactly where static analysis earns its keep.

If this article has you wanting to check your own project, you can try the analyzer free.

See you in the next articles!

Game++. Part 1.4: Game engine architectures

Unicorn Developer — Fri, 03 Jul 2026 14:38:04 +0000

This book offers insights into C++, including algorithms and practices in game development, explores strengths and weaknesses of the language, its established workflows, and hands-on solutions. C++ continues to dominate the game development industry today thanks to its combination of high performance, flexibility, and extensive low-level control capabilities.

CryEngine (Microkernel Architecture)

In the early 2000s, as developers sought ways to create more realistic and immersive game worlds, a unique game engine emerged, offering a completely new approach to architecture. CryEngine, developed by the German studio Crytek, revolutionized the industry with its stunning graphics and cutting-edge microkernel architecture.

It all started with a tech demo called "X-Isle: Dinosaur Island." Built by a rather small team, the demo turned heads among publishers and developers alike. Back then, most game engines relied on a monolithic architecture with tightly coupled components, but the Yerli brothers (Avni, Faruk, and Cevat Yerli) had a different vision. Inspired by the design of the QNX operating system, they applied the principles of microkernel architecture to a game project. This laid the foundation for an engine that would later become one of the most technologically advanced of its time.

Investors and studios put their faith in this approach, in which CryEngine isolates only critical functions in the central core, while the remaining components run as separate modules. Such modularity enabled developers to swap out components without destabilizing the whole system. Some implementations took it further, allowing individual logic modules and dynamic libraries to be reloaded at runtime, making it possible to update NPC behavior and fix logic bugs without restarting the game—only truly critical errors would cause a crash. Even then, a fallback handler could swap in the default module, reconnect the failed components, and let the session continue. This architecture also made it practical to create new features, as well as debug and optimize subsystems, without having to rebuild the entire engine. The brothers pushed the idea of supporting multiple genres on a single technology base, but it didn't quite work out, leaving CryEngine with the "best engine for FPS" reputation.

The first commercial game to demonstrate the power of the microkernel approach was Far Cry (2004), which impressed players with its vast open areas, long draw distances, and realistic vegetation, as well as a world that responded dynamically to the player's actions. The second version of CryEngine, used in Crysis (2007), became the technical benchmark for the new generation of graphics hardware, setting the standard for rendering performance; meanwhile, the phrase "But can it run Crysis?" became a meme among gamers.

The microkernel approach behind the engine left a mark on the entire game development industry, pushing concepts like scalability, fault tolerance, and cross-platform adaptability into the mainstream. Other engines began adopting similar practices. In fact, after the release of Crysis 2, scalability and adaptability became standard expectations in engine development.

CryEngine, like all major game engines at the time, was cross-platform from release. The renderer supported OpenGL and DirectX 8/9 and was designed for open environments; a single game level could contain areas spanning up to three square kilometers. The physics system was built entirely in-house, yet that never compromised its quality. It handled rigid bodies, fluids, vehicles, cloth simulation, soft-body objects, and ragdoll physics—in every respect, the technology reached an exceptionally high standard for a proprietary solution.

Its inverse kinematics technology allowed layering multiple animations onto a single model at once, which made character movement look far more natural. A module written in Lua, rather than C++, handled the NPCs' AI. The scripts could be changed without recompiling, a rare feature at the time. CryEngine also gave us Far Cry and its many expansions, as well as the MMORPG AION. NCSoft licensed CryEngine for AION, although the company later reworked it extensively to fit the demands of multiplayer online games.

In 2004, following the release of Far Cry, the shader module gained support for Shader Model 3.0, and the engine was updated to 1.2. Shaders unlocked a long list of visual effects: per-pixel lighting, bump-mapped reflections, refraction, smoke, animated textures, transparent computer screens, see-through surfaces, and bullet decals. One particularly notable feature was the fog rendering, which looked far more realistic than what competing engines of that era could pull off.

In March 2006, Ubisoft acquired full rights to the Far Cry franchise, along with a license to CryEngine. This covered the entire IP, including the trademark, logo, characters, story, and setting, as well as exclusive rights to the source code and the underlying technology—meaning the original team could no longer use any of the old code to develop a new engine.

After Crytek released the final patches for Far Cry, development of the technology split into two separate paths. Ubisoft, now holding the Far Cry franchise and a licensed copy of the engine's source code, went on to develop its own version for Far Cry Instincts and Far Cry Instincts: Evolution on Xbox, Far Cry Instincts: Predator on Xbox 360, and Far Cry Vengeance for the Nintendo Wii. According to Louis-Pierre Farand, lead producer on Far Cry 2, the resulting Dunia Engine retained only 2–3% of the original CryEngine's source code (Pic. 2.7).

Picture 2.7

In turn, Crytek's developers continued developing their own technology platform and created a new engine, CryEngine 2, which marked the next step in its evolution and was fully independent of Ubisoft. Like its predecessor, the engine was written in C++, but unlike the original, it did not aim for cross-platform support. It targeted a single platform: Microsoft Windows with DirectX. At the time of its release, CryEngine 2 ranked among the most technologically advanced and photorealistic game engines on the market, setting new standards for rendering, physics, and dynamic environments. However, its demanding hardware requirements and dependence on Windows and DirectX limited its audience to owners of high-end gaming PCs.

The engine kept every feature from the previous version and even improved most of them. CryEngine 2 handled massive open environments just as effectively, while a new asset streaming system allowed levels to load dynamically as the player progressed. Crytek was also among the first studios to ship a 64-bit build of a game. Because game worlds had grown considerably since Far Cry, rendering them took far more system resources, making 32-bit systems inadequate.

The microkernel architecture remained intact as well: the compiled engine was split into separate DLLs, with each component packaged as its own library and loaded on demand during gameplay. This meant developers could swap out or modify individual pieces without touching the rest of the engine.

CryPhysics, the new in-house physics engine Crytek built for this version, was designed for multithreading from the start and fully integrated into CryEngine 2. It opened the door to far more extensive physics interactions and allowed the engine to apply physics simulation to nearly every object in a level, including trees and vegetation, so they reacted realistically to gravity, wind, explosions, and collisions.

As with the previous version, the transition to CryEngine 3 came with friction, both within the team and among executives. A completely different team took over development, so the results were a mixed bag: some parts impressed, others fell flat. CryEngine 3 was officially announced on March 11, 2009, and released that same year on October 14. The first game to use the new engine was the first-person shooter Crysis 2.

The engine was originally developed with DirectX 11 support, but Crysis 2 shipped without it—as well as DirectX 10—until a patch came out. The likely reason was Crytek's push to turn Crysis 2 into a cross-platform release. One major drawback of staying PC-exclusive was piracy: every legitimate copy sold was reportedly matched by about ten pirated downloads. As a result, the studio shifted its focus toward consoles.

Modern versions of CryEngine continue to build on the ideas behind its microkernel architecture while gradually expanding the use of AI in both tooling and graphics. The philosophy established by the Yerli brothers left a lasting mark on the game industry, proving that modularity, flexibility, and scalability can coexist with high performance.

A related branch of the technology now lives on as an open-source engine, O3DE, which evolved from Amazon Lumberyard. Lumberyard was based on a 2015 version of CryEngine, whose source code is available separately. Amazon licensed the CryEngine source code, refactored and reorganized the project, and released it on GitHub as Lumberyard under a proprietary license. Later, the company handed the project over to the community as O3DE, making it freely available as open source. By the time it became open source, more than $50 million had reportedly been invested in the technology—some estimates place that figure above the development costs of Unity and Unreal Engine, or at least on a comparable level. The original modular architecture now takes the form of independent Gem components that developers can freely add to or remove from a project (Pic. 2.8).

Today, O3DE remains under active development. Although the engine offers a rich feature set, it has yet to achieve the same level of adoption as Unreal or Unity.

Picture N2.8

Dagor (Data-driven Architecture)

Among many well-known game engines, many of which trace back to the United States, there are a few notable exceptions from Eastern Europe that have shaped the industry in their own way. One such example is Dagor Engine, developed by Gaijin Entertainment. The engine stands out not only for its technical features and its ability to run on virtually any platform with a GPU and at least some kind of CPU, but also for its distinctive architecture built around data-driven design principles. Today, it's publicly available, so anyone can explore what's under the hood.

The engine's history goes back to the early 2000s, when an in-house game development tool gained wider recognition after the release of IL-2 Sturmovik: Birds of Prey (2009). The game showed that the engine could handle complex physics models, render realistic visual effects, and put data-driven design to real use.

Data-driven architecture is an approach where application logic comes mainly from data rather than being hard-coded in the source. For game engines, that means most elements of the game world—objects and their behavior included—are described in data files such as JSON, XML, or other structured formats. The engine interprets these files at runtime, which brings a few clear advantages. Data and code stay separate. Objects and their properties are defined declaratively—describing what should happen rather than how to implement it. And configuration becomes dynamic, letting developers make changes without recompiling or even restarting the game. Put together, these traits naturally evolve into a component-based system that's defined and configured entirely through data.

In traditional engines, changing game object behavior often requires writing or modifying code, recompiling it, and then testing the result. Here, game designers and artists can adjust object parameters, effects, and even core behavior simply by editing data files—effectively making changes on the fly. During an internal tournament for one of the studio's games, the admins spawned random level objects mid-game by simply dropping blk files (Dagor's equivalent of JSON) into the level folder. Cars, weapons, fridges, and a couple of tanks started appearing out of nowhere for the players.

Data-driven architecture pairs naturally with a component-based approach to designing game objects. Over time, developers start thinking this way by default and can't imagine working otherwise. In Dagor Engine, each object can be built from a set of components, with each one handling a specific functional aspect. This makes it easy to create new object variations just by combining and configuring existing components. Once again, all of this happens on the fly, without recompiling the engine and often without even restarting the game.

Contrary to the common belief that runtime data interpretation slows games down, a well-designed data-driven architecture can still deliver high performance. The evidence is indirect but visible: the company's games run at acceptable frame rates on mobile devices and the Nintendo Switch, neither of which is exactly known for raw power.

The resource system is a cornerstone of the data-driven architecture. The engine organizes all game data into a hierarchical structure of configs, each with a unique identifier and loadable on demand. In Dagor Engine, the code might look something like this:

/data/
/vehicles/
/tanks/
/t-34/
model.blk textures/
diffuse.dds normal.dds specular.dds
weapons.blk collision.blk


/weapons/
/guns/
/85mm_zis/ ballistics.blk Visual_effects.blk

The *.blk files are a special structured data format used in the engine. While similar to JSON in function, they are optimized for fast loading, efficient processing, and overriding of sections and properties. When loading, the game can pull in values to override object properties from another config. It typically looks something like this:

visual_effects.blk graphics {
rendinstDistMul:r=0.5 grassRadiusMul:r=0.1
}
visual_effects.@1.blk graphics {
override@rendinstDistMul:r=0.8
}

The final configuration ends up with rendinstDistMul = 0.8.

Despite all its advantages, data-driven architecture also comes with serious drawbacks. The first is debugging complexity. Since behavior comes from data rather than code, debugging takes a lot more effort and usually needs specialized tools to track how data changes ripple through the system. In real projects, this often means maintaining separate visual debugging tools tailored to a specific engine.

The second drawback is interpretation overhead. However efficiently the engine optimizes data processing, runtime interpretation still introduces additional costs compared to hard-coded logic.

Pic. 2.9 shows the systems developers can configure just by modifying scripts, without rebuilding the entire engine—and, as you can see, that covers almost the entire engine.

X-Ray Engine (Monolith Architecture)

The history of the video game industry is full of technologies that arrived ahead of their time. One such example is the X-Ray Engine, created by programmers Alexander Maksimchuk and Oles Shishkovtsov for the S.T.A.L.K.E.R. series. The game was originally going to be about robots on some unknown planet filled with anomalies and lasers. At some point the team realized they did not need to invent either the planet or the robots—the perfect anomalous zone with the perfect atmosphere already existed just a three-hour drive from their office.

Picture N2.9

First shown back in 2001, the engine went on to become the foundation for one of the most immersive gaming worlds ever created. Its graphics held up impressively well for the time. The engine could render up to four million polygons on screen, far beyond what even many late-2000s games could handle. It managed large-scale environments just as well, whether enclosed interiors or open areas reaching up to two square kilometers. On top of that, it ran a full dynamic day-night cycle with lighting changes, along with weather effects like rain, wind, and fog. The dynamic lighting in particular still impresses, producing memorable shots and an atmosphere that's hard to forget even now.

For physics, X-Ray relied on the open-source Open Dynamics Engine (ODE), also released in 2001. It handled rigid-body dynamics and collision detection, and worked well for simulating vehicles, creatures, and objects in a dynamic environment. On paper, the engine's integration system was stable enough that physics shouldn't have broken down without reason. In reality, players of the first S.T.A.L.K.E.R. game soon got very familiar with all kinds of physics anomalies—from flying bodies to bizarre object behavior. Those quirks eventually turned into one of the series' signature traits, inspiring memes and funny clips. Well, it simply fit the nature of the Zone—after all, anomalies are part of the setting.

This engine is a textbook example of monolithic architecture (not to be confused with a unitary one). It is divided into separate parts, but those parts are tightly bound together rather than loosely coupled. Unlike systems where components operate relatively independently, X-Ray Engine functions as a tightly integrated whole, with all components deeply interconnected.

Monolithic architecture (Pic. 2.10) brings both clear advantages and serious drawbacks. Tight integration across graphics, physics, and AI—and the ability to build gameplay mechanics directly off how components interact—enabled developers to use and plan resources more efficiently through custom allocators, object packing, fast message queues, and similar techniques. With no abstraction layers standing between components, interaction stayed direct and fast, which mattered a lot on the hardware available at the time. Developers could precisely control memory usage and CPU time, which proved critical for a project this demanding.

This unified structure also meant the engine, the game world, development tools, and subsystems could share one coherent vision, with everything working together naturally. Removing or isolating any individual part would inevitably reduce functionality and hurt overall performance.

However, the same characteristics that boost performance can also limit scalability, make individual components harder to update, and introduce various challenges, especially on multicore systems. As the system grows, maintaining it and fixing bugs becomes exponentially more difficult, since changes in one part often ripple through neighboring subsystems.

In fact, complexity ended up being the biggest technical issue of the X-Ray Engine. Beyond the random crashes familiar to every fan—hello, "bug trap"—the engine also suffered from micro-freezes and brief stutters that showed up across every game in the S.T.A.L.K.E.R series. They were especially bad in Shadow of Chernobyl, where, in extreme cases, the game could turn into a slideshow while running at a normal frame rate. The root cause was architectural: the engine relied heavily on a single CPU core, a limitation that only became more painful as multicore systems took over.

Picture 2.10

The last official version of the engine is X-Ray Engine 1.6.02, used in Call of Pripyat. The fan community didn't stop there, though. Enthusiasts kept refining the technology, creating unofficial engine versions that fixed many critical issues, introduced new features, and—most importantly—added support for multicore processors and multithreading.

Technical problems aside, the engine remains an important milestone in the history of game development. Its strengths—dynamic lighting, advanced physics, and the A-Life simulation system—were years ahead of their time and gave players plenty of standout moments. And perhaps this monolith really did make someone's dream game a reality.

Monolithic architecture—with all its strengths and weaknesses, and above all when applied deliberately—serves as an excellent example of a particular approach to building game engines. It also offers a valuable lesson for the industry as a whole. The engine's core concepts and many of the practices developed around it would later inform the 4A Engine, built by former members of the team for the Metro series.

Godot (Modules/Services Architecture)

From the outside, the game development industry may seem to advance at a rapid pace: new rendering technologies, new approaches to rigging, better-looking models, voice acting, and the growing use of AI for animation. Under the hood, however, all these things still rely on well-tested, established solutions that are extremely difficult to replace or change in any fundamental way. I would even argue that, outside conference talks, game development remains highly conservative. Big studios avoid risks, while smaller teams often lack the time and resources to take them, even when they'd like to. Real architectural innovation is rare. Against this backdrop, the adoption of concepts from the web—as seen with the Godot engine and microservices architecture—becomes particularly interesting.

Most architectural styles receive their names once communities or conference speakers notice a recurring pattern and start shaping it into something more defined—there is no secret council of architects deciding what the next major trend will be. More often, developers independently arrive at similar solutions as an engine's ecosystem evolves and new challenges emerge. The approaches that prove most effective at adapting to change and leveraging it eventually become recognized architectural patterns that others follow. Microservices stand out here, because when the concept first emerged, no game engine or game actually followed those principles. In fact, the term gained recognition through the article "Microservices" by Martin Fowler and James Lewis, published in 2014. In that article, the authors laid out the common traits of this relatively new architectural style. Looking at Godot, I see many of those same ideas at work. At its core, the microservices approach breaks a complex system into numerous small, autonomous services, each providing a specific set of features.

In the context of game development with Godot, this idea evolves into a microservice-like architecture where the game no longer exists as a monolithic mass of code but as a system of components that talk to each other. Physics, AI, UI, and the audio system—each of these elements can exist as a separate module with a clearly defined way of interacting with the rest. I would not call this approach perfect, but it does allow developers to focus on individual aspects of the game without constantly worrying about how a change might affect the rest of the project.

Godot first appeared in 2014 and has since won over many developers thanks to its simplicity and reliability. Its name comes from the character who never arrives in Samuel Beckett's play Waiting for Godot. What sets Godot apart is how it organizes game logic through a system of nodes and scenes. Imagine a construction set where every piece of the game—from a character to an interface—is a separate building block that snaps easily to others. Although Godot wasn't originally designed with microservices in mind, its node-based architecture and modularity ended up fitting that philosophy surprisingly well. The result was an architecture where different components can be developed almost entirely independently of each other.

Godot's signal mechanism provides a particularly elegant way to connect these components. Imagine a player picking up an item: the inventory system emits a signal, and other systems can react to it. The UI updates, the achievement system logs progress toward whatever is being collected, and a special abilities system recalculates character stats. None of these systems needs to know how the others work—or, in some cases, even that they exist at all.

In fact, the engine's core philosophy revolves around adding new features by creating new modules rather than modifying existing ones. Developers can reuse component modules across different projects, and if a module has a bug, it is less likely to affect the entire game. Of course, no game can be broken down into modules indefinitely, but this approach at least cuts the chances of the entire thing crashing due to a single faulty component.

That said, this architecture is no silver bullet—though for smaller projects it often works exceptionally well: you snap together a set of component modules, wire up their signals, and—voilà—everything comes together and works as intended. As a project grows, though, the sheer number of interactions and gameplay systems tends to introduce excessive complexity and slow things down. The signal system can become a bottleneck, while modules may start competing for updates. The real takeaway is that micro-modules only make sense where they provide a clear benefit. For example, separating game logic from visual presentation almost always pays off. On the other hand, splitting tightly coupled mechanics into independent services or modules often leads to unnecessary complexity later on.

Another important distinction is that, unlike traditional microservices in web development—which run as separate processes or even on different machines—all game components operate within the same process (or a small number of processes). This sidesteps a lot of communication and synchronization headaches typical of classical microservice systems, the kind of problems that would only get in the way at such a small scale.

Even so, this approach has gained a dedicated following: more than a dozen relatively large games shipped on Godot in 2024 alone. That may not sound impressive compared to the thousands released on Unreal Engine or Unity, but it is a significant achievement for a project maintained primarily by a handful of core developers and its community.

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: Game engine architectures

Game++. Part 1.2: Game engine architectures

Game++. Part 1.3: Game engine architectures

Code slicing: What lies inside OrcaSlicer

Unicorn Developer — Tue, 30 Jun 2026 14:19:06 +0000

How can you avoid overlooking dangerous code parts during reviews? You can use static analysis tools. Let's take as an example OrcaSlicer, a popular slicing software designed to prepare 3D models for printing. We'll take a peek under its hood and see what surprises await us.

About the project

There's a cool project on GitHub that helps prepare 3D models for printing. It can convert a 3D model into machine instructions for creating an object layer by layer.

OrcaSlicer is one of the most popular free open-source slicers. The project is quite large, and its primary development language is C++, which is exactly why it caught my attention. Today, let's take a look under the hood and explore some of the code's highlights.

Note. The purpose of this content is to promote static analysis technology, not to offend the authors of OrcaSlicer.

The article simply shows that even functioning projects can contain bugs. Developers may overlook issues during code reviews or testing, and they accumulate over the years, which can ultimately lead to defects in the product. However, using additional tools, such as static analyzers, helps developers detect bugs before they reach production.

If you still doubt the value of such tools, I recommend reading the article "Why you should choose the PVS-Studio static analyzer to integrate into your development process."

Let's dive in

I analyzed this project commit using PVS-Studio plugin for Visual Studio 2022. The article doesn't cover every warning the analyzer issued, only the ones I found the most interesting.

Note. To improve readability, the code snippets have been formatted, and some have been hidden behind comments marked with // .....

Example N1

PVS-Studio warning: V655 The strings were concatenated but are not utilized. Consider inspecting the 'message + "\n\nApplication will close."' expression. GUI_App.cpp 7170

bool GUI_App::load_language(wxString language, bool initial)
{
  // ....
    if (!wxLocale::IsAvailable(locale_language_info->Language)) {
    // Loading the language dictionary failed.
    wxString message =   "Switching Orca Slicer to language "
                       + requested_language_code + " failed.";
#if !defined(_WIN32) && !defined(__APPLE__)
      // likely some linux system
      message += "\nYou may need to reconfigure the missing locales, "
                 " likely by running the \"locale-gen\" "
                 "and \"dpkg-reconfigure locales\" commands.\n";
#endif
    if (initial)
      message + "\n\nApplication will close.";              // <=
    wxMessageBox(message, "Orca Slicer - Switching language failed", 
                 wxOK | wxICON_ERROR);
    if (initial)
      std::exit(EXIT_FAILURE);
    else
      return false;
  }
  // ....
}

Here's a typo that developers missed during code review. The code uses + instead of +=, so the string literal never gets appended to the message variable. The code compiles, but it makes no sense. This warning reminded me of an error we caught in qbEngine, where devs forgot to add the # character in the #else macro.

When looking at this code, one might think: "No way! I'd never write something like this." It's simply a mistake a human can do, though. This code has been in the project for four years, yet it still hasn't been fixed. At the same time, the fragment where the message string is initialized was modified just a couple of months ago.

Example N2

PVS-Studio warning: V1047 Lifetime of the lambda is greater than lifetime of the local variable 'do_stop' captured by reference. FillBedJob.cpp 250

void FillBedJob::process(Ctl &ctl)
{
  // ....
  bool do_stop = false;
  // ....
  params.on_packed = 
    [&do_stop] (const ArrangePolygon &ap)
    {
      do_stop = ap.bed_idx > 0 && ap.priority == 0;
    };
  // ....
}

The lambda expression captures the do_stop local variable by reference and then stores it in params.on_packed. However, do_stop is destroyed when the process method exits because the lifetime of the local object ends. If the lambda runs after the member function returns, it will access a destroyed object, resulting in undefined behavior.

Capturing by value would solve this issue, but the lambda modifies the do_stop variable, so this approach won't work. Instead, do_stop can be turned into a member of the FillBedJob class.

This pattern repeats two more times in the code:

V1047 Lifetime of the lambda is greater than lifetime of the local variable 'statustxt' captured by reference. FillBedJob.cpp 245
V1047 Lifetime of the lambda is greater than lifetime of the local variable 'do_stop' captured by reference. FillBedJob.cpp 241

Example N3

PVS-Studio warning: V768 The enumeration constant 'roPortrait' is used as a variable of a Boolean-type. RasterBase.hpp 81

class RasterBase {
public:

  enum Orientation { roLandscape, roPortrait };

  struct Trafo {
    bool mirror_x = false, mirror_y = false, flipXY = false;

  TMirroring get_mirror() const 
    { return { (roPortrait ? !mirror_x : mirror_x), mirror_y}; }  // <=
  // ....
  };
// ....
}

The analyzer detected an enum value being used as the first operand in a ternary operator. The roPortrait constant has a value of 1, so the condition is always true. Most likely, the developers should've used another variable here.

Alternatively, an additional parameter may have been needed to compare it with roPortrait, as done in the constructor:

  Trafo(Orientation o = roLandscape, const TMirroring &mirror = NoMirror)
    // XY flipping implicitly does an X mirror
    : mirror_x(o == roPortrait ? !mirror[0] : mirror[0])          // <=
    , mirror_y(!mirror[1]) // Makes raster origin to be top left corner
    , flipXY(o == roPortrait)
  {}

Example N4

PVS-Studio warning: V781 The value of the 'm_load_slot_index' variable is checked after it was used. Perhaps there is a mistake in program logic. Check lines: 2152, 2155. AMSItem.cpp 2152

void AMSRoadUpPart::doRender(wxDC& dc)
{
  // ....
  dc.SetPen(wxPen(_get_diff_clr(this,
  m_amsinfo.cans[m_load_slot_index].material_colour), 4, wxPENSTYLE_SOLID));
  auto temp = m_amsinfo;
  if (m_load_step != AMSPassRoadSTEP::AMS_ROAD_STEP_NONE){
    if (m_amsinfo.cans.size() <= m_load_slot_index || m_load_slot_index < 0){
      BOOST_LOG_TRIVIAL(trace) << "up road render error";
      return;
    }
  // ....
}

These errors are especially intriguing because they seem impossible to make at first glance. The case may seem simple, but it's actually quite confusing. If we look through the list of issues the V781 diagnostic rule detected, we can see that even developers working on fairly large projects make these mistakes quite often.

What's the problem, though? It's array index out of bounds. First, the m_load_slot_index index is used to access an element of the m_amsinfo.cans vector, only then it's checked whether the iterator is out of bounds or negative. The check exists, but it happens too late. We can fix the code by placing the check earlier or handling this case differently.

The same warning:

V781 The value of the 'i' index is checked after it was used. Perhaps there is a mistake in program logic. ViewerImpl.cpp 56

Example N5

PVS-Studio warning: V783 Iterator 'it' is checked after it was used. Perhaps there is a mistake in program logic. Check lines: 3159, 3160. Selection.cpp 3160

void Selection::ensure_not_below_bed()
{
  // ....
  if (is_any_volume()) {
    for (unsigned int i : m_list) {
      GLVolume& volume = *(*m_volumes)[i];
      const std::pair<int, int> instance = 
        std::make_pair(volume.object_idx(), volume.instance_idx());
      InstancesToZMap::const_iterator it = instances_max_z.find(instance);
      const double z_shift = SINKING_MIN_Z_THRESHOLD - it->second;
      if (it != instances_max_z.end() && z_shift > 0.0)
        volume.set_volume_offset(Z, volume.get_volume_offset(Z) + z_shift);
    }
  }
  // ....
}

This fragment contains another check that also appears after the iterator is used. Theit iterator is dereferenced to calculate z_shift, and the next line contains a check whether it differs from the end() iterator. If the element isn't found, dereferencing the resulting iterator leads to undefined behavior.

The fixed code:

if (it != instances_max_z.end())
{
  const double z_shift = SINKING_MIN_Z_THRESHOLD - it->second;
  if (z_shift > 0.0)
    volume.set_volume_offset(Z, volume.get_volume_offset(Z) + z_shift);
}

Example N6

PVS-Studio warnings:

V595 The 'part_plate' pointer was utilized before it was verified against nullptr. Check lines: 498, 525. ObjectDataViewModel.cpp 498

V522 Dereferencing of the null pointer 'part_plate' might take place. The null pointer is passed into 'AddPlate' function. Inspect the first argument. Check lines: 497, 535. ObjectDataViewModel.cpp 497

wxDataViewItem ObjectDataViewModel::AddOutsidePlate(bool refresh)
{
  wxDataViewItem plate_item = AddPlate(nullptr, _L("Outside"));         // <=
  m_plate_outside = (ObjectDataViewModelNode*)plate_item.GetID();

  return plate_item;
}

// ....

wxDataViewItem ObjectDataViewModel::AddPlate
  (PartPlate* part_plate, wxString name, bool refresh)
{
  int  plate_idx  = part_plate ? part_plate->get_index() : -1;          // <= 1 
  wxString plate_name = name;
  if (name.empty()) 
  {
    plate_name = _L("Plate");
    plate_name += wxString::Format(" %d", plate_idx + 1);
    if (!part_plate->get_plate_name().empty())                          // <= 2
    {
      plate_name += wxString(" (",
        wxConvUTF8) + from_u8(part_plate->get_plate_name()) + wxString(")",
        wxConvUTF8);
    }
  }
  // ....
  for (int obj_idx = 0; obj_idx < m_objects.size(); obj_idx++) {
    auto obj_node = m_objects[obj_idx];
    if (part_plate && part_plate->contain_instance_totally(obj_idx, 0)){// <= 3
      ReparentObject(plate_node, obj_node);
    }
  }
  return plate_item;
}

This is a long snippet, so let's break it down step by step. The AddOutsidePlate member function calls AddPlate and passes nullptr as the first argument. The part_plate parameter is checked two out of the three times where it's used. If a check is missing somewhere, the compiler may assume that the other checks are unnecessary as well and remove them for optimization purposes.

We can fix the code by adding the missing check. Here's a fun fact: if we look at the commit history, we can see that there was originally a ternary operator there, but the code was later rewritten.

Example N7

PVS-Studio warning: V797 The 'find' function is used as if it returned a bool type. The return value of the function should probably be compared with std::string::npos. HintNotification.cpp 175

TagCheckResult tag_check_material(const std::string& tag)
{
  if (const GUI::Tab* tab = wxGetApp().get_tab(Preset::Type::TYPE_FILAMENT)) 
  {
    // search PrintConfig filament_type to find if allowed tag
    if (wxGetApp().app_config->get("filament_type").find(tag))
    {
      const Preset& preset = tab->m_presets->get_edited_preset();
      const auto* opt = 
        preset.config.opt<ConfigOptionStrings>("filament_type");
      if (opt->values[0] == tag)
        return TagCheckAffirmative;
      return TagCheckNegative;
    }
    return TagCheckNotCompatible;
  }
  return TagCheckNotCompatible;
}

The code contains a comment explaining that a tag needs to be found. Below is the condition where the tag is searched for. However, it doesn't work as intended:

if the tag is found at the beginning, find returns 0, which is converted to false;
if the tag is found somewhere in the middle, find returns a positive number, which is converted to true;
if the tag is not found, find returns std::string::npos, which is also converted to true.

As a result, the condition doesn't check whether the tag was found. Instead, it checks whether the tag isn't located at the beginning of the string. The fix may look like this:

if (wxGetApp().app_config->get("filament_type").find(tag) != std::string::npos)

Example N8

PVS-Studio warning: V714 Variable 'face' is not passed into foreach loop by a reference, but its value is changed inside of the loop. MeshBoolean.cpp 153

template<class _Mesh> 
  void triangle_mesh_to_cgal(const TriangleMesh& M, _Mesh& out)
{
  // ....
  // Number the faces because 'orient_to_bound_a_volume' 
  // needs a face <--> index map
  unsigned index = 0;
  for (auto face : out.faces())          // <=
    face = CGAL::SM_Face_index(index++);
  // ....
}

The analyzer reports a suspicious range-based loop: the face loop variable is declared as a copy of the current element from the out.faces() range, but the code modifies it on every iteration. Most likely, the code was intended to modify elements inside the out.faces() range.

If you need to modify elements within a range, declare the loop variable as an lvalue reference:

for (auto &face : out.faces()) 
  face = CGAL::SM_Face_index(index++);

Let's also make sure that the elements in the out.faces() range aren't the same as std::reference_wrapper.

Spoiler: no, they aren't

template <typename I>
class Iterator_range
  : public std::pair<I,I>
{
public:
  I begin() const
  {
    return this->first;
  }

  I end() const
  {
    return this->second;
  }

  template <typename T>
  Iterator_range<T>
  make_range(const T& b, const T&e)
  {
    return Iterator_range<T>(b,e);
  }

  // .... 
};

template <typename T>
class SM_Index
{
// ....
public:
  typedef boost::uint32_t size_type;
  // ....
protected:
  size_type idx_;
};

class SM_Face_index
  : public SM_Index<SM_Face_index>
{ /* .... */ };

typedef SM_Face_index Face_index;

template <typename P>
class Surface_mesh
{
// ....
private:
  template<typename Index_>
  class Index_iterator
    : public boost::iterator_facade< Index_iterator<Index_>,
                                     Index_,
                                     std::random_access_iterator_tag,
                                     Index_
                                   >
  {
    // ....
  private:
    friend class boost::iterator_core_access;
    // ....
    Index_ dereference() const { return hnd_; }

    Index_ hnd_;
    const Surface_mesh* mesh_;
  };
  // ....
public:
  typedef Index_iterator<Face_index> Face_iterator;
  typedef Iterator_range<Face_iterator> Face_range;

  Face_iterator faces_begin() const
  {
    return Face_iterator(Face_index(0), this);
  }

  /// End iterator for faces.
  Face_iterator faces_end() const
  {
    return Face_iterator(Face_index(num_faces()), this);
  }

  Face_range faces() const {
    return make_range(faces_begin(), faces_end());
  }
  // ....
};

There's a lot of code here, so let's try to break it down. In the triangle_mesh_to_cgal function template, the out parameter has the _Mesh template type. Most often, function template arguments are specializations of the Surface_mesh class template.

In the private class section, the template of the Index_iterator iterator, which inherits from [boost::iterator_facade](https://www.boost.org/doc/libs/latest/libs/iterator/doc/facade-and-adaptor.html), is defined. Essentially, this class template simplifies iterator implementation. Let's take a look at its template parameters:

template <
    class Derived // The derived iterator type being constructed
  , class Value
  , class CategoryOrTraversal
  , class Reference   = Value&
  , class Difference  = std::ptrdiff_t
>
class iterator_facade

The fourth template parameter specifies the [reference](https://cppreference.com/cpp/iterator/iterator_traits) type, which is the value the iterator returns when dereferenced. If it isn't specified explicitly, reference defaults to Value &.

The Index_iterator class template we're interested in passes its own template type as the fourth argument. This means dereferencing the iterator returns a copy of Index_. The Index_ template parameter is of the Face_index type. This is an alias of the SM_Face_index type, which doesn't define any data members and inherits from the SM_Index class template. The SM_Index class template defines a single idx data member of the boost::uint32_t type, which is a built-in integral type.

I find it difficult to say what the code should've looked like here, since changing the face variable type to auto & doesn't seem like a valid fix. Moreover, the code should stop compiling because an lvalue reference can't bind to a prvalue object.

When Face_iterator is dereferenced, it returns a copy of the Face_index object. To modify anything within the out.faces() range, the iterator would need to return a reference and somehow be connected to the Surface_mesh internal data. In that case, the range-based for loop would work correctly. However, Surface_mesh and its iterator come from a third-party library, and I doubt we can make any changes there.

Example N9

PVS-Studio warning: V609 Divide by zero. Denominator range [0x0..0x7FFFFFFFFFFFFFFF]. TreeSupport3D.cpp 811

[[nodiscard]] static Polygons safe_offset_inc(....)
{
  if (distance == 0)
    return do_final_difference ? diff(ret, collision_trimmed())
                               : union_(ret);

  if (safe_step_size < 0 || last_step_offset_without_check < 0) {
    BOOST_LOG_TRIVIAL(warning) 
      << "Offset increase got invalid parameter!";
    tree_supports_show_error(
      "Negative offset distance... How did you manage this ?"sv, true);
    return do_final_difference ? diff(ret, collision_trimmed())
                               : union_(ret);
  }

  coord_t step_size = safe_step_size;
  int steps = distance > last_step_offset_without_check 
                ? (distance - last_step_offset_without_check) / step_size
                : 0;
  // ....
}

The analyzer reports a division by zero. To understand what's happening, we'll start from the end. The step_size variable equals safe_step_size, which means the division by zero occurs if safe_step_size == 0.

At the beginning of the function, there's a safe_step_size < 0 check, which catches only negative values and doesn't check for zero. This means the function doesn't return early when safe_step_size == 0, which eventually leads to a division by zero.

This issue appears quite often and is related to using the constants 0, 1, and 2. We noticed this pattern and even wrote an article about it: "Zero, one, two, Freddy's coming for you."

Other V609 warnings:

V609 Divide by zero. Denominator range [0..2]. GCode.hpp 303

Example N10

PVS-Studio warning: V593 Consider reviewing the expression of the 'A = B < C' kind. The expression is calculated as following: 'A = (B < C)'. PerimeterGenerator.cpp 1057

template <typename LineType>
class LinesDistancer {

  using Floating = typename std::conditional<
    std::is_floating_point<Scalar>::value, Scalar, double>::type;
  template<bool SIGNED_DISTANCE> Floating distance_from_lines(/*.... */)
  //....
}

std::tuple<std::vector<ExtrusionPaths>, Polygons> 
  generate_extra_perimeters_over_overhangs(....)
{
  // ....
  for (size_t i = 0; i < overhang_region.front().polyline.size(); i++)
  {
    Point p = overhang_region.front().polyline.points[i].to_point();
    if (double d = 
      lower_layer_aabb_tree.distance_from_lines<true>(p) < min_dist)
    {
      min_dist = d;
      min_dist_idx = i;
    }
  }
  // ....
}

The devs wanted to write clean code, but overlooked operator precedence. The < operator has higher precedence than assignment, so the d variable receives the result of the comparison—a bool value instead of double. As a result, min_dist gets either 0 or 1 instead of the actual distance. Here's how we can fix this:

double d = lower_layer_aabb_tree.distance_from_lines<true>(p);
  if (d < min_dist)

Alternatively, we can fix it like this if the compiler supports the if statement with an initializer (C++17):

if (double d = lower_layer_aabb_tree.distance_from_lines<true>(p);
    d < min_dist)

Example N11

PVS-Studio warning: V766 An item with the same key '"open"' has already been added. DialogButtons.hpp 69

class DialogButtons  : public wxPanel
{
private:
  const std::map<wxString, wxStandardID> m_standardIDs = {
    // Choice
    {"ok"         , wxID_OK},
    {"yes"        , wxID_YES},
    {"apply"      , wxID_APPLY},
    {"confirm"    , wxID_APPLY}, // no id for confirm, reusing wxID_APPLY
    {"no"         , wxID_NO},
    {"cancel"     , wxID_CANCEL},
    // Action
    {"open"       , wxID_PRINT},  // <=
    {"open"       , wxID_OPEN},   // <=
  //....
}

Two elements with the open key were added to the initialization of std::map. A container can't store multiple elements with the same key, so the second element won't be added.

Looking at the values, we can see that the key for wxID_PRINT wasn't updated after copying. As a result, the wrong value will be used. The fix may look like this:

    {"print"      , wxID_PRINT}, 
    {"open"       , wxID_OPEN},

Other V766 warnings
V766 An item with the same key '"use_firmware_retraction"' has already been added. Print.cpp 229
V766 An item with the same key '"filament_notes"' has already been added. Print.cpp 237
V766 An item with the same key '"nozzle_volume"' has already been added. PrintConfig.cpp 8201
V766 An item with the same key '"inner-outer-inner wall/infill"' has already been added. PrintConfig.cpp 272

Example N12

PVS-Studio warning: V734 An excessive expression. Examine the substrings "plus" and "xplus". QidiPrinterAgent.cpp 375

std::string QidiPrinterAgent::infer_series_id
  (const std::string& model_id, const std::string& dev_name)
{
  // ....
  if (   (   key.find("xplus") != std::string::npos 
          || key.find("plus") != std::string::npos)
      && key.find("4") != std::string::npos)
  {
    return "0";
  }

  return "";
}

The analyzer detected an unnecessary call in the condition. If key contains the xplus substring, it also contains plus. The second find("plus") check is redundant because it will always evaluate to true whenever the first one does. Checking plus is enough:

if (key.find("plus") != std::string::npos && key.find("4") != std::string::npos)

The code also looks rather inefficient: the string is iterated over three times.

Example N13

PVS-Studio warning: V583 The '?:' operator, regardless of its conditional expression, always returns one and the same value: wxEmptyString. Search.cpp 96

static Option create_option
  (const std::string &opt_key, const wxString &label,
   Preset::Type type, const GroupAndCategory &gc)
{
  wxString suffix;
  wxString suffix_local;
  if (gc.category == "Machine limits") {
    //suffix       = opt_key.back() == '1' ? L("Stealth") : L("Normal");
    suffix       = opt_key.back() == '1' ? wxEmptyString : wxEmptyString;
    suffix_local = " " + _(suffix);
    suffix       = " " + suffix;
  }
// ....
}

There's a typo in the ternary operator: both branches return wxEmptyString. The condition doesn't affect the result. The commented-out line above indicates that the code previously had different logic, but it works differently in its current form.

The exact same code was copied to another snippet as well:

V583 The '?:' operator, regardless of its conditional expression, always returns one and the same value: wxEmptyString. Search.cpp 348

Example N14

PVS-Studio warning: V670 The uninitialized class member 'm_result' is used to initialize the 'm_options_z_corrector' member. Remember that members are initialized in the order of their declarations inside a class. GCodeProcessor.cpp 1671

class OptionsZCorrector
{
  GCodeProcessorResult& m_result;

public:
  explicit OptionsZCorrector(GCodeProcessorResult& result) : m_result(result) {
  }
// ....
}
class GCodeProcessor
{ 
  // ....
  OptionsZCorrector m_options_z_corrector; // line: 811
  // ....
  GCodeProcessorResult m_result;           // line: 843
  // ....
}
GCodeProcessor::GCodeProcessor()
: m_options_z_corrector(m_result) 
{
  // ....
}

An uninitialized variable is used in the constructor initialization list. Class data members initialize in the order they're declared, and in this code, m_options_z_corrector initializes before m_result.

Currently, the code works correctly because memory for the object gets allocated before initialization begins. In this case, it's possible to retrieve the address and read it, which is exactly what happens in the OptionsZCorrector constructor. However, if the constructor starts using the m_result variable, it will lead to undefined behavior.

To fix the code, the data member declarations in the class should be reordered so that m_result appears before m_options_z_corrector.

Looking ahead

If you wish to minimize errors in your projects, incorporate static analysis into your regular workflow—and PVS-Studio can help you do just that.

You can request pricing, a trial version, or learn about free licensing terms in the relevant sections.

Look ahead to your project's future and catch errors as early as possible :)

JS & TS digest: ES2026 updates, runtime showdown, and PVS-Studio EAP

Unicorn Developer — Fri, 26 Jun 2026 12:32:06 +0000

While frontend engineers keep rebuilding their projects around new build tools, JavaScript itself keeps getting faster, safer, and more mature. Here's the most interesting JS and TS news from the past few months.

Introducing ES2026: what's new in the standard?

TC39 has officially approved a list of features for ECMAScript 2026. The language continues to shed its old "baggage":

Explicit Resource Management (the using keyword). This feature has been in development for a long time in TypeScript and finally landed in native JavaScript. Now you can automatically allocate resources as soon as a variable goes out of scope.
Iterator Helpers (new methods for iterators). You no longer need to convert iterators to arrays using Array.from() just to call .map() or .filter(). Lazy evaluation is now available right out of the box.

You can track the progress of these features and their status in the official TC39 GitHub Proposals repository. The Explicit Resource Management and Iterator Helpers features are now in the final development stages.

Runtime Showdown: Node.js against the World

In 2026, Node.js finally cemented its status as a mature development environment that successfully adopts features from newer competitors (Bun and Deno). The biggest trend this year in runtime environments is running TypeScript files without third-party tools or transpilers like ts-node, thanks to fast built-in parsers.

Full details are on the Node.js Official Blog.

TypeScript 7.0: Beta announcement and migration to Go

On April 21, 2026, Microsoft officially released TypeScript 7.0 Beta. This isn't just a minor update but a major revolution under the hood.

The tsgo compiler. The development team has fully ported the existing type-checking logic from the old JS/TS engine to the new native compiler written in Go.
10x faster. Go's multithreading brings a tenfold speedup in build and type-checking times for large projects, compared to 6.0.
Architectural parity. The language's semantics remained the same: Microsoft carefully moved the framework's code to ensure that existing projects wouldn't break during the transition. The new feature is already being tested extensively at Slack, Google, Figma, and Vercel.

Early Access: PVS-Studio's new JavaScript & TypeScript analyzers

We've spent years specializing in C, C++, C#, and Java—but web development has grown too important to ignore. We're now building new analyzers for JavaScript and TypeScript, and we'd like you to try them!

PVS-Studio is currently running the Early Access Program. As part of the EAP, our priority is to check whether the new analyzers are stable, perform well, and produce high-quality analysis on real projects. We invite you to participate in the testing: sign up here.

What to read?

TypeScript Tips Everyone Should Know

This article provides a roundup of practical TypeScript techniques for improving safety, readability, and developer experience. For example, the author advises using safe input data validation, fewer unnecessary type signatures, satisfies instead of rough type casting, etc. More useful patterns are in the full article.

Error that we had to ignore

Developing a static analyzer, as with any software project, involves trade-offs. Sometimes this means dropping perfectly valid analyzer warnings to make the tool better overall. The article illustrates this trade-off through a diagnostic rule designed to detect typos caused by identical operands in binary expressions.

JavaScript in 2026: A Comprehensive Guide to the Ecosystem Revolution

If you missed the Runtime Wars, you can read this comprehensive overview. You'll explore how fierce competition between Node.js, Bun, and Deno has forced all players to implement native TypeScript support and built-in security tools. This is a great long-read article for understanding where the entire industry is headed.

TypeScript at scale in 2026: What senior engineers should know

This article focuses on how to effectively use TypeScript in large codebases, monorepos, and large teams. The author points out that by 2026, the question of whether to use TypeScript is no longer relevant. The language has become the standard, shifting the focus toward efficiently managing code at the system level.

What to listen?

Podcast: TypeScript.fm

If you've been searching for a focused, lively show about TypeScript, this is it. Hosts Kamran Ayub and Erik Onarheim cover the latest language updates. In a recent episode, they discussed the updates to TypeScript 7.0 Beta and debated why the new tsgo compiler sometimes uses too much memory.

Podcast: Syntax.

Meet one of the well-known podcasts on frontend and full-stack development, hosted by Wes Bos, Scott Tolinski, and CJ Reynolds. No fluff, just a strong focus on practice and experience. Every week, they release episodes in a variety of formats: from in-depth analyses of complex bugs in JavaScript and TypeScript to relaxed Supper Club interviews with creators of top-tier libraries, frameworks, and modern automation tools like Biome, ESLint, and Vite.

Wrap-up

Thank you for reading our digest! Share with us any other fresh news or events you find noteworthy. You can submit them using our feedback form.

To stay up to date on the latest news, follow us on X and LinkedIn. We post articles by our company's experts, video reviews featuring the latest analyzer updates, event announcements, memes, and much more. Most importantly, you're always welcome to leave comments—we'll be happy to respond!

Don't forget, PVS-Studio stands guard over your codebase.

Get the 30-day trial promo code here!

We're building custom programming language—would you join us?

Unicorn Developer — Tue, 23 Jun 2026 14:24:50 +0000

What is expertise, and what lies at its core? Expertise varies in depth, field, and purpose. But some things never change: it can't exist without theory and experience; it can't emerge in an environment free from challenges and mistakes. Every person develops their own unique expertise. Today, we'll share our experience, which may inspire you to enhance your expertise. Also, we invite you to challenge your brain and guess some unexpected inventions.

What gives rise to expertise in programming? In the past, it was curiosity—the urge to simplify and overcome challenges. Today, it shaped by projects that deliver business value. But even now, we can arm ourselves with those qualities and reach the outcomes we aim for. After all, code lets us stay flexible and venture down untrodden paths. Quite often, they can lead to the beginning of something much greater—and history has plenty of proof.

Below, you'll find stories of such unexpected success. Can you guess what invention each one describes? Share your guesses in the comments or read the article to the end, where we'll reveal all the secrets.

Story #1

A Danish-Canadian developer wanted to create a convenient tool for tracking visits to his online CV. The solution proved so useful and effective and quickly went beyond personal use. It still remains popular among web developers. What is the solution?

Story #2

Two developers set out to solve the problem of migrating software from 32-bit to 64-bit systems. They created a tool to help detect errors the transition caused. Later, they realized it could also find other issues and transformed it into a full-featured tool that could handle a wider range of tasks. What the solution does?

Story #3

An engineer came up with this solution to fix an issue in his online store where items would simply disappear from the cart when users navigated to another store section. Today, this discovery powers the entire world of online advertising and user tracking.

What does expertise mean for PVS-Studio?

We hope you guessed what the solutions were. Now, let's go back to the main topic: expertise. Why does our company value it? How does it reveal itself in our work? Now we'll show how our new practice helps transform our expertise into benefits for the developer community.

We work closely with programming languages because our mission is to help developers write clean code. Our devs should understand languages down to their core to create algorithms that detect common and critical errors, as well as potential vulnerabilities in code. This expertise enables us to teach computers how to automatically identify issues.

The number of diagnostic rules that catch issues in your projects continues to grow every year.

What stands behind these rules, though? What does the analyzer rely on when searching for errors? It's the core! It powers our data flow analysis, signature analysis, method annotations, and all our other analysis technologies. Yuri, our core architect, handles this and other numerous areas. He's a great engineer, a proud cat dad, and simply a cool guy. While going through yet another epic battle with core-level challenges—it's hard to imagine what he deals with every day while diving so deep into the tool's innards—Yuri was pulled away from his usual work by an offer from his colleagues...

PVS-Studio has a department called Te&De (Teaching & Development). Two wonderful employees, Inna and Yulia, handle internal trainings for our employees. They also organize live talks for managers and developers.

You can find information about the upcoming and past talks here.

They suggested Yuri share his knowledge in the internal training course for new employees. As the course took shape, we realized that its content would benefit not only new colleagues, but also the broader dev community. This led to the decision to make the materials publicly available for free.

A few words about the series of live talks

Since Yuri isn't a fan of text storytelling, we took it upon ourselves to introduce his original series of live talks about creating a toy programming language where he explains what lies behind almost every programming language. Understanding how it works is one thing—teaching a machine to understand it is a much harder challenge.

It all starts with grammar, which describes the language structure.

When it comes to parsing code, the lexer takes the stage. It extracts individual words from the text and classifies them.

The next step is to put words into sentences. This is where the parser comes into play. It takes the words and turns them into language constructs. Then, we organize these constructs into a syntax tree, a hierarchical structure that represents relationships between individual language parts. We traverse the tree and execute or evaluate what it describes.

A language also consists of different entities that we can name—and it must recognize and understand these names. This is where semantic analysis comes in. Languages also have data types that interact with each other, and determining how they work together is part of semantics.

The final piece is the evaluator that traverses the syntax tree and calculates the values of variables and expressions.

This is roughly what a programming language looks like in a simplified and idealized form. In the live coding sessions, Yuri walks through the entire process while viewers can ask questions and discuss the details.

Our main goal isn't to teach but to satisfy the curiosity that drives many programmers to dive deeper into the topic. We also want to transform the experience gained from building a static analysis tool into exciting content and share this expertise with others. The steps Yuri goes through when creating his own language form the foundation, but it isn't as simple as it may seem. This series of sessions, designed to help developers build their own language, is one of the easiest ways to understand how programming languages actually work.

By the way, if you'd like to join Yuri on this journey, there's still time! The next session dedicated to building an Abstract Syntax Tree is scheduled for June 26, 1:00 PM UTC+1. Sign up here and don't forget to check your inbox to confirm the registration!

Revealing secrets

While doing our work, we often run into challenges. If we stop, we might miss something important and truly remarkable. But when overcoming a problem, we feel proud of ourselves and gain experience and new skills. By encouraging curiosity, we explore new horizons, sometimes simplify complex things, and open doors we never even knew existed at the beginning of our journey. Now, it's time to lay our cards on the table and tell you what solutions we had in mind.

Story #1

The Danish-Canadian developer's name is Rasmus Lerdorf, and his invention is Personal Home Page (a set of tools for a personal homepage). It became popular and eventually evolved into PHP, a widely used programming language for websites. Lerdorf combined his scripts with a form-handling library, introducing the basic syntax, and the option to process data from HTML forms. The release of PHP 2.0 turned it into a full-fledged tool for building dynamic websites, revolutionizing web development.

P.S. One of our designers created this image for another article. It's amazing how large our collection of illustrations has grown over the years, especially considering the exceptional talent of each artist. Recently, our colleague wrote an article on how our mascot, Cody the Unicorn, has changed throughout the entire company's history. Check out this article and enjoy the delightful collection of unicorn illustrations and some of the most unconventional designs.

Story #2

Of course, it's PVS-Studio. We decided to praise ourselves a little :)

It was 2006, the dawn of 64-bit systems. Back then, many devs were thinking about moving away from 32-bit systems, but the transition brought its own share of 64-bit bugs. As a result, two developers created a mechanism to catch such errors and later turned it into a tool that tackled a much wider range of issues. Today, PVS-Studio is a full-fledged company. Back then, it started with two recent grads who had a problem, and their solution grew into something much bigger. By the way, the company recently turned 18—they grow up so fast!

Story #3

In 1994, Netscape Communications engineer Lou Montulli encountered an issue: the original HTTP protocol was stateless, meaning a server couldn't track when the same user moved from page to page or made purchases. He suggested storing a small piece of text data on the user's side. These became known as cookies. This invention forever changed the web industry by making it possible to create user-friendly shopping carts for online stores and enabling users to stay logged in to websites.

Some parting words

The PVS-Studio team wishes you success in enhancing your expertise. It's a valuable skill that'll help you grow and reach new heights. We also invite you to join our live talks, where you can gain new insights into programming languages and find inspiration for your projects, whether personal or professional. Your curiosity may also lead to something bigger. All you need is right here...

"They generate more bugs, more security holes": C++ creator takes aim at vibe coding

Unicorn Developer — Mon, 22 Jun 2026 13:46:59 +0000

Bjarne Stroustrup, the creator of the C++ programming language, says modern AI tools still aren't reliable for writing high-quality, complex system code or designing programming languages. Bjarne raised the point on the Ryan Peterman podcast.

"I think that in the field I'm mostly interested in code will still be written by humans, and they will use abstraction. The examples I've seen of attempts for AI to generate code in this domain has not been successful. They generate more bugs, more security holes."

Stroustrup points to validation as the real problem: AI-driven changes are harder to track because a small prompt change can spread across many parts of a project.

"All of the code that was generated knows more code generated than if it was written by humans. When a human makes a change, it will make a change that's localized. You can look for the effects of that localized change. If an AI writes it, you don't actually know where it's changed. You have to try and figure that out."

However, the "father of C++" doesn't dismiss AI entirely. He believes that it can be useful for technical writing, provided human reviews the output.

"It's not, at least now, good at safety-critical, performance-critical code. Now, let's say that 70 or 80% of the world's code doesn't fit that pattern. But it's that 10 or 20% of the code that I'm interested in. And there, it's not there."

The podcast also touched on LLMs. Stroustrup has noted that they're trained on existing code, which means they may inherit old approaches and old habits along with it.

"I find that LLM-based code is imitating old code and getting old performance and old bugs again. Maybe you can improve that. I hear rumors of Bjarne apps being written that fit my writings, but even that is problematic because I'm not saying exactly the same as I did 20 years ago."

The PVS-Studio team, which builds a static analysis tool with a strong focus on C++, also shared their perspective on the widespread adoption of AI-driven coding.

Phillip Khandeliants, Head of Static Analyzer Development at PVS-Studio

"Bjarne Stroustrup's criticism lands when a developer just copies and pastes the AI output into a project. Depending on the prompt, the model may generate code that's suboptimal, buggy and/or even insecure. We have seen evidence of this when reviewing vibe-coded projects like vib-OS or markus. To be fair, the authors of those projects did not aim to ship a production-level solution, but rather to run a case study.
We shouldn't forget that AI-generated and human-written code are no longer different in one matter: they both need to be thoroughly checked. It should go through an extensive code review, static and dynamic analysis, and formal verification processes. Used that way, AI agents can significantly streamline developers' workflow by handling boilerplate, routine tests, and early hypothesis generation, ultimately boosting productivity and development speed."

Oleg Lisiy, C++ Team Lead at PVS-Studio

"Absolutely, AI is just part of how people work now, and that's not going away. The real question is how we should leverage it. Letting an AI agent generate code from an issue description and then push it straight to production has no place in enterprise-level software development. It's hard to imagine anyone actually doing this way.
On the other hand, if criticize AI, we should criticize IDE's autocomplete too, shouldn't we? Just imagine a developer mashing random keys, hitting Tab for autocomplete, and committing the result right away. Sounds crazy, doesn't it? The hype around AI feels just as crazy to me."