DEV Community: Unicorn Developer

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

Unicorn Developer — Thu, 18 Jun 2026 13:27:09 +0000

This is the fourth part in our series of talks on creating a programming language. In this session on building our toy programming language, we focus on the parser, specifically on parsing expressions using recursive descent.

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.

Meet the parser

The parser verifies whether input conforms to the grammar and, if successful, builds an abstract syntax tree (AST). Yuri walks through the grammar for additive, multiplicative, unary, parenthesized, and literal expressions, explaining how precedence and left associativity are baked into the grammar structure.

Parser implementation

It begins with a straightforward but repetitive version, where separate functions handle additive and multiplicative expressions. This leads to code duplication, especially as more binary operators are added. To solve this, the presenter introduces a generic binary expression function that uses a precedence enum and recursive calls with an increased index. This approach eliminates duplication and handles all binary operators uniformly.

Yuri demonstrates how the parser descends through the grammar, consuming tokens and building nested structures, with left associativity ensured by loops that repeatedly consume operators of the same precedence.

The session concludes with a preview of future topics: building an AST, implementing a builder and printer, and using the visitor pattern.

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. AST.

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

See ya!

Game++. Part 1.3: Game engine architectures

Unicorn Developer — Tue, 16 Jun 2026 14:27:46 +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.

Before jumping into game engine architectures, it helps to define what we mean by software architecture and how it relates to games.

First, architectures are a real thing in game dev, whatever anyone says. Second, there turns out to be more than one. Keeping that in mind makes the rest of this chapter much easier to follow and gives you something to say the next time someone goes off about why a particular engine is either pure genius or complete garbage.

Most projects follow a similar pattern: code gets written, tools get built, a game gets shipped. The skeleton grows flesh, and only then do all the ignored problems come knocking because getting something out the door was always the priority. But sweeping problems under the backlog rug doesn't make them disappear.

Every program has an architecture, even if everything lives inside a single main() and somehow holds together on optimism and luck. The more interesting question is: what actually makes a game engine good?

Nobody builds an engine for fun. Engines grow from necessity—as development progresses, individual pieces get formalized and stabilized so they can be reused. An editor appears, then an asset pipeline, a dedicated I/O module, a renderer that earns its own codebase, and so on. Eventually a team of engineers gathers around all those systems to keep them running. Most teams only realize this after shipping—by then it's clear that you simply can't keep working the old way.

Another approach is for the game itself to be the editor, the engine, and the build system all in one—something that can compile itself into finished levels and logic. All game engines and editors grew out of games. Some of those games (and later engine-editors) became successful, and their developers rode that wave to buy more time and resources to keep building. Over time, somebody on the team (grown from within, rarely hired) takes on the job of keeping the growing machinery together, ensuring integrity within the whole system. Sometimes that person carries the title of Architect. More often, they are an engineering veteran who's spent years working alongside programmers, designers, QA, and production.

For the last ten-plus years I've spent every working day staring at the code of different games and engines, mostly large ones that have been around long enough to grow beards. Like any programmer who's spent a long stretch in one domain, I'd like to think I've developed an eye for good design or, at least, a nose for bad design. Every developer has lived through that moment when the code they were looking at was so bad that the only honest move was to comment it out and rewrite everything around it. Of course, "best technical decision" and "approved by management" are rarely the same thing. Terrible legacy systems often survive for a reason: they are ugly, but battle-tested. Everybody already knows where the landmines are. New code may look cleaner, but you still have to discover its hidden threats.

Few of us have been lucky enough to work with perfectly designed code. That very code, project, or engine that feels like a luxurious American sedan from the '70s—one that has everything you could want, you just need to know where the controls are—and it's ready to hit 100 fps with just a light tap of the gas pedal. Anyway, working with different codebases, I started noticing that game engines often resemble the teams that build them.

Once a team grows beyond five or six developers, some kind of organization becomes unavoidable—responsibilities naturally split along the lines of skill and experience. Everybody does what they know best: the internal database, the renderer, physics, the editor, tests, and so on. From a business standpoint that division looks perfectly logical—the right people in the right seats, less overlap, better efficiency.

Split the team and you split the knowledge, and suddenly different parts of the system struggle to interact effectively. Development then bogs down as specialists dig deeper in their own isolated subsystems and stop talking about the things that actually affect everyone. That artificial divide ultimately hampers knowledge sharing and leaves the engine's components poorly integrated with each other.

This pattern—the link between an engine's structure and the internal organization of the team behind it—was noted back in the 1960s by Melvin Conway. Conway's Law states that the structures of the organizations involved in designing a system will ultimately be reflected in the architecture of that system. Put simply, it's hard for a team to build something that doesn't end up looking like the way they communicate.

This isn't specific to engines, it goes for any team-built software. A company split into frontend, backend, and database teams rarely ships a system where those boundaries don't show—the architecture quietly inherits the org chart, whether anyone intended that or not.

Note. According to Johnny Leroy, the way to fix a broken architecture is to fix how the team communicates first. The architecture and the team that builds it have to grow in the same direction. Instead of building a system that inherits organizational weak spots, you reshape the organization so it naturally grows something more integrated and flexible.

If the architecture demands tight integration between different parts—say, between gameplay and the renderer—don't keep these teams working in separate corners. Get them talking directly: cross-functional groups, pair programming, or cross-review practices. The knowledge starts flowing and the architecture shifts with it.

A small warning before we continue. In the text below, the architectural labels may not be industry-standard and may be debatable.

Unity (Unitary Architecture)

The first time I looked seriously at Unity's internals—not the editor, but the engine architecture underneath—I was mildly horrified. This was around 2014, so perhaps some things have changed, but I'd not bet heavily on it. By then, Unity had already conquered mobile development. I expected a polished architecture and a carefully engineered roadmap. Instead I faced a patchwork quilt of components with three build systems haphazardly thrown together and sealed with a mono-VM. Just like "if it builds, don't touch it", even if it means workarounds everywhere and comments like "Don't remove this space", "Don't compile on Independence Day", or "Build with this constant first; if it doesn't compile, set it to 0." At one point, building the editor involved a separate wiki page listing 117 steps: compile this first, rebuild that second, set these flags, pray if it fails. And the editor had its own separate build system on top of that. But the origin story of Unity explains a lot.

It all started with GooBall, a game dreamed up in 2001 by students David Helgason, Joachim Ante, and Nicholas Francis. Their studio, Over the Edge Entertainment, ran into the classic indie problems of the early 2000s: expensive engine licenses, complex code, and a lack of resources. The guys shipped the game, but four years of struggle ended in commercial failure. What came out instead—built on that same game source code, those same approaches, and that same team—was Unity.

In 2005, Unity 1.0 was quietly shown at an Apple conference. An engine built for macOS X seemed to have little chance in a world where almost everyone played on Windows. But that turned out to be its advantage: the Mac was popular with designers, and shortly afterward it became a common platform for early iPhone development.

Unity stood out right away. Rather than wrestling with complex code, Unity's component-based approach lets you assemble objects like LEGO bricks—snap on physics, animation, or scripts. A visual editor, rare for the mid-2000s, meant you could just drag things around with a mouse. Support for C# plus a simplified UnityScript made scripting approachable. The industry took notice.

The turning point came in 2008 when Unity shipped on Windows, multiplying its audience tenfold. The real liftoff, though, happened two years later with the Unity Asset Store—a marketplace of ready-made models, textures, and scripts, most of it a dollar or free, which was manna from heaven for indie studios and solo developers. At the same time, the engine added iOS and Android support, right as smartphones exploded. Suddenly, one laptop and a good idea felt like enough to build a game. That's how Temple Run (2011) and Monument Valley (2014) came to be. EA, Blizzard, and Ubisoft followed in 2011, signing long-term support deals and licensing the source code for internal use. By 2015, nearly half of mobile developers were using Unity.

The internals still resembled a large patchwork quilt: three different build systems, a pile of reinvented wheels, a partially modified EASTL library sitting alongside Boost and the standard C++ library. Different parts of the engine could use different STL versions, which meant copying data at the boundaries, for example, between the renderer that used EASTL and the editor which had its own custom classes and containers.

Tack on Mono with its own data exchange layer and you end up with a classic game engine architecture of the early 2000s. Not to be too uncharitable, I call this kind of architecture "unitary".

You may have heard the saying that programming languages come in two kinds: the ones people complain about, and the ones nobody uses. This analogy seems to fit here. For what it's worth, I have genuine respect for this engine, so don't let any of the above mislead you.

Big Ball of Mud

Code that grows without structure has a name: Big Ball of Mud, an anti-pattern popularized by Brian Foote in the 1990s. Among my colleagues I've also heard variations like Cup of Mud, Fancy Barrel, and Dirty Feet.

Note

"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems."

Brian Foote

In practice, a "unitary" architecture may describe, for example, a simple game where event handlers are wired directly to handling logic without internal buffering or dispatching. Most games start out that way, and it works fine until it doesn't. For a tiny game with a few mechanics and screens, it's no big deal. But the codebase keeps growing. Without structure, every change turns into an uphill struggle, and sooner or later releases, testing, scalability, and performance all start to hurt.

This anti-pattern is everywhere. Hardly anyone sets out to create a "unitary" architecture, but poor quality control and a lack of structural discipline will get you there eventually. Within such a system, any change in one class can break something completely unrelated, making every bug fix or tweak a gambling nightmare. At its worst, the project ends up as a jumble of source files, resources, and engine-technical files.

What started as a three-student project is now maintained by a team of 400 engineers. Unity Technologies employs 5,000 people, fewer than 10% of whom are programmers. Picture 2.1 shows a block diagram of Unity Engine, and there's nothing to worry about at first glance... Until you dig deeper into the C++ guts and try to change something.

By this point the "simple" architecture hasn't been simple for a while. Everything talks to everything: managers depend on other managers, states reference one another, events fire when nobody expects them to. Try to fix one thing and two others break. Changing one feature suddenly requires rebuilding half the dependency graph. The longer it goes without cleanup, the scarier the code becomes to touch. The cost of developing new features skyrockets under these conflicts, when you can't say what affected what, and where it's going to blow up.

Components never designed for reuse become traps for anyone new to the codebase. With no clear boundaries, dependencies, or isolation, reliability decreases. As a result, developers grow afraid to make changes, and the project stagnates. Picture 2.1 shows an overview of the Unity engine (version 4, 2014), and Picture 2.2 shows a class-dependency diagram where each chord represents a relationship between the classes and subsystems shown in Picture 2.1.

Picture 2.1

Picture 2.2

The Cup of Mud architecture (or a legacy bog) describes localized pockets of mess inside an otherwise orderly codebase. Individual functions, classes, or modules become islands of chaos: a function may have dozens of parameters, multiple nested conditions, and mixed logic from different levels of abstraction. These spots usually start as temporary fixes or emergency patches that nobody ever got around to cleaning up. Smaller in scale than a Big Ball of Mud, these pockets still breed bugs and slow development down, as developers avoid touching them.

Fancy Barrel is about code with a clean, attractive API that hides chaotic, poorly organized internals. It boasts good documentation, elegant method names, and modern design patterns on the surface, while the architecture remains tangled and unstructured. A beautiful facade that conceals a "barrel" of technical debt and creates a false impression of quality engineering. The problem surfaces the moment you need to extend something or fix a bug. At that point the pretty interface is all you have to show for it.

Dirty Feet ("as if someone has tracked mud through the whole house") and Pigsty both describe code that has left a mess scattered across the system. The hallmark is broken encapsulation, where changes in one module force modifications in dozens of seemingly unrelated components. Anyone working in this codebase ends up poking around in unrelated corners of the system to implement a single feature, eroding logic and building up hidden dependencies. The result is code that's hard to test and even harder to isolate, as every component drags in a pile of side effects and demands complex setup.

Unreal Engine (Layered Architecture)

In 1991, Tim Sweeney, the founder of Epic Games (at the time just Epic MegaGames), started building editing tools for his first titles. It all began with a top-down adventure-puzzle game called ZZT, with bare-bones graphics (Picture 2.3).

Picture 2.3

Players explored maze-like levels, fought enemies, and solved small puzzles, all rendered in plain ASCII characters in DOS text mode. ZZT was never going to turn heads for its graphics or gameplay at the time, but Tim's approach to programming—and especially the built-in ZZT-OOP level editor—established the modularity principles that later evolved into Unreal Engine.

ZZT proved successful, bringing its author about $100 a day in shareware sales. Enough to convince Sweeney that game development might actually be a real career instead of a hobby. Hiring a small team from a level-design contest for ZZT, he moved the business out of his parents' house, and a five-person team got to work on the next project—Jill of the Jungle. In 1992, Epic shipped Jill of the Jungle (Picture 2.4), a DOS platformer that introduced more advanced tools such as sprite animation, movement physics, and particles. The bigger shift was a growing emphasis on a component-based approach: Tim built objects from data structures based on standard engine components, making it possible to override object behavior without touching the rest of the code. You could create new enemy types, change their AI, or add interactive level elements through scripts.

At a time when most studios essentially rebuilt their technology from zero for every game, Tim's approach was different. He separated the game into three distinct layers:

the engine (low-level systems: rendering, physics, sound);
the content (assets and base logic);
the scripts (configuration files and high-level logic).

Those ideas grew into something bigger. In 1998, Epic released the first version of Unreal Engine alongside the game Unreal.

The structure of the first engine-game looked more disciplined—rendering, shared systems, scripting, tools, and editing workflows existed as relatively independent pieces. On top sat UnrealEd, while gameplay logic leaned on UnrealScript, an object-oriented scripting language with class inheritance that made modding significantly more accessible.

Picture 2.4

Picture 2.5

Other technical advances followed: dynamic collision, 16-bit color, richer lighting, and tools that let developers run and tweak parts of the game directly in the level editor. The game was a hit, selling over 1.5 million copies. In 1999 Epic released its second game, Unreal Tournament, which was a "lessons learned" exercise that added built-in networking support to the engine.

In 2002, Epic released Unreal Engine 2, debuting publicly alongside America's Army—a free multiplayer shooter built to boost public interest in military service. It was the first time the army had used large-scale game technology for a public audience; the game picked up several player-voted awards along the way.

Although Epic's primary focus remained PC game development, Sweeney and his team once again recognized where the market was heading: toward consoles. The idea of creating a single engine that would allow developers to release games on both PCs and the Sony PlayStation 2, Nintendo GameCube, and Microsoft Xbox was highly appealing. Unreal Engine 2 also reflected Sweeney's interest in modularity—unlike many competitors of the era, Epic avoided treating each engine release as a frozen artifact. So, after its first drop in 2002, the engine was regularly updated and modified.

Flexibility became another key pillar of Unreal Engine 2. While previous engines from other companies were mostly locked to a single genre—first-person shooters—the Epic team recognized that giving developers the freedom to work across genres would be a huge competitive edge. Integrating the Karma physics engine, a particle system, and other new capabilities quickly turned UE2 into an industry standard, powering titles such as BioShock and Thief: Deadly Shadows.

Unreal Engine 3 shipped in 2006, with the first Gears of War as its flagship. The engine's growing platform support opened the door to iOS and Android releases. This update was aimed more at the player-facing side of things—the internal architecture stayed largely unchanged, but the renderer got a significant overhaul: per-pixel lighting, better physics, and much more.

Game developers often rely on layered architecture to keep their codebase well-organized. Even though Unreal Engine was shaped by one specific person's vision for a long time, it scaled well to a large team, giving the engine and its subsystems both structure and room to grow.

Looking at how the engine's components connect (Picture 2.6), it's clear that while different parts still talk to each other, there are far fewer connections than you might expect. A layered architecture maps naturally onto a component system: scene objects, physics, or scripts—each sitting at its own level of abstraction. This ends up becoming the de facto standard and the architectural foundation for most studios building games on top of the engine.

Once again, back to Conway's Law, which says that codebase structure tends to mirror the way teams are organized, and Unreal is a textbook example. Its development team is split into focused groups—UI/input, gameplay, AI (responsible for NPCs, interactive objects, and enemies), and a dedicated engine-optimization team. This structure naturally tends to show up in the game teams building with the engine. And yet, individual developers may take on tasks beyond their usual scope or complete internships in other teams—this is just part of how Epic operates.

Picture 2.6

People are people, and developing with Unreal can be surprisingly comfortable—comfortable enough that teams sometimes slip into a "default architecture," following the engine's templates and conventions without questioning the reasoning behind them. A project can even drift into a "unitary" architecture, where developers simply start coding without a clear plan. For a while the layered structure the engine provides holds things together, but again, without real discipline behind it, the codebase gradually devolves into a Big Ball of Mud.

As of 2023, Epic Games has around 4,000 employees worldwide, spanning game teams, publishing, the store, and the engine itself. Open-source estimates put the number of people working directly on the engine somewhere between 500 and well over 1,000. That includes around 200 programmers focused on graphics, physics, and optimization. Beyond them, there are technical support engineers who maintain the GitHub repository and handle incoming commits, as well as technical writers and course engineers. Developers for VR/AR and mobile, and a large division dedicated to Virtual Production, CAD integration, and support for major game and film studios—together adding roughly 400 more people.

Author: Sergei Kushnirenko

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

All parts

Game++. Part 1.1: C++, game engines, and architectures

Game++. Part 1.2: C++, game engines, and architectures

Changes to PVS-Studio's student licensing policy

Unicorn Developer — Mon, 15 Jun 2026 12:16:53 +0000

We have updated the licensing terms regarding the free use of the tool by students and teachers. Here is a breakdown of the changes.

A couple of months ago, we discussed changes to PVS-Studio's free licensing policy and mentioned our plans to update the process of obtaining licenses for students and teachers. The update is finally complete, and here's how everything works now.

To obtain a student license, select the Student License option in the trial key request form and submit the request using your university email address (with the university domain). Upon request, we will issue you a temporary one-month license.

You can learn more about PVS-Studio's student licensing terms here.

In addition, you can use the Compiler Explorer website, which allows you to write, compile, and run programs in various programming languages online. You can check C and C++ code using PVS-Studio directly from the platform interface.

You can also get a free license for open-source projects. For more information, follow this link.

Error that we had to ignore

Unicorn Developer — Fri, 05 Jun 2026 13:23:12 +0000

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. In the article, we'll look at a real-life example of that kind of compromise.

Background

For the context, we're actively developing a static code analyzer for JavaScript and TypeScript, which is currently in beta (and we'd love for you to join it).

But back to the point: I've been working on the V7001 diagnostic rule, which detects typos in the form of identical operands in binary expressions:

let baz = foo – foo // foo - bar
if (foo == foo) { // foo == bar
  // ....
}

It also focuses on more complex cases like nested expressions:

(a && b) || (c && d) || (a && b)

And expressions that are not identical but equivalent:

(a * b) > (b * a)

If you're curious about how our JavaScript diagnostic rules perform in practice, we've covered some findings from open-source projects in the separate article.

More noise than signal

Right after I finished writing this diagnostic rule, I ran analysis on our project database and found this code snippet in pdf.js:

flagValues: Object.freeze({
  applyOverPrint: 1,
  applySoftProofSettings: 1 << 1,
  applyWorkingColorSpaces: 1 << 2,
  emitHalftones: 1 << 3,
  emitPostScriptXObjects: 1 << 4,
  emitFormsAsPSForms: 1 << 5,
  maxJP2KRes: 1 << 6,
  setPageSize: 1 << 7,
  suppressBG: 1 << 8,
  suppressCenter: 1 << 9,
  suppressCJKFontSubst: 1 << 10,
  suppressCropClip: 1 << 1,
  suppressRotate: 1 << 12,
  suppressTransfer: 1 << 13,
  suppressUCR: 1 << 14,
  useTrapAnnots: 1 << 15,
  usePrintersMarks: 1 << 16,
}),

The code defines a set of conversion flags used to control printing. Each flag represents a single option, and the flags can be freely combined using bitwise operations. The flags are grouped by categories: color correction, transformation suppression, fonts, and so on. However, there's something off in this code. See that?

The PVS-Studio warning: V7001 The operands of the '<<' operator in the '1 << 1' expression are equivalent. print_params.js 90

The warning points to the line between the 10th and 12th flags:

suppressCJKFontSubst: 1 << 10,
suppressCropClip: 1 << 1,
suppressRotate: 1 << 12,

Perhaps, this code is a child of Ctrl+C and Ctrl+V, with the field name and flag number changed manually in each line. But in one place, 1 << 1 was never replaced with 1 << 11. One digit missing among a sea of ones, no wonder it could go unnoticed.

This code has just been added and isn't called anywhere yet, so it doesn't cause any issues. And yet, when the time comes, applySoftProofSettings and suppressCropClip will behave as a single flag. All in all, this is a good catch for the analyzer, it found a real error here.

Hide the pain Harold

However, if you run PVS-Studio for JavaScript or TypeScript today, you won't see this warning. Why? While we were developing this diagnostic rule, the analyzer output a huge number of similar warnings—but the vast majority of them looked like this:

Angular

export enum InputFlags {
  None = 0,
  SignalBased = 1 << 0,
  HasDecoratorInputTransform = 1 << 1,
}

The PVS-Studio warning: V7001 The operands of the '<<' operator in the '1 << 1' expression are equivalent. core.ts 49

Babel

const enum PRINTER_FLAGS {
  EMPTY = 0,
  PRESERVE_FORMAT = 1 << 0,
  COMPACT = 1 << 1,
  CONCISE = 1 << 2,
  RETAIN_LINES = 1 << 3,
  RETAIN_FUNCTION_PARENS = 1 << 4,
  AUX_COMMENTS = 1 << 5,
}

The PVS-Studio warning: V7001 The operands of the '<<' operator in the '1 << 1' expression are equivalent. index.ts 10

Here's pdf.js again.

const ON_CURVE_POINT = 1 << 0;
const X_SHORT_VECTOR = 1 << 1;
const Y_SHORT_VECTOR = 1 << 2;
const REPEAT_FLAG = 1 << 3;
const X_IS_SAME_OR_POSITIVE_X_SHORT_VECTOR = 1 << 4;
const Y_IS_SAME_OR_POSITIVE_Y_SHORT_VECTOR = 1 << 5;
const OVERLAP_SIMPLE = 1 << 6;

The PVS-Studio warning: V7001 The operands of the '<<' operator in the '1 << 1' expression are equivalent. glyf.js 17

These are just 3 out of 42 similar warnings among the total number of the V7001 warnings (126) in the test database. As you can see, the analyzer flags 1 << 1 everywhere it appears Technically, it's not wrong: shifting a number by 1 rarely makes sense outside of very niche scenarios. The result of the 1 << 1 operation will always be 2. And the only thing the notation does is make the interpreter fold the constant during compilation into machine code.

But here we're dealing with bit flags, where readability and consistency matter more than abstract performance gains. That's the reason why developers usually arrange bit flags into a clean, sequential list with the flag numbers on each line—after all, the overhead from the extra operation is truly negligible.

Interestingly, the analyzer will also fire a false positive on 1 << 1 in the code snippet provided earlier—yet another strike against such a pattern.

applyOverPrint: 1,
applySoftProofSettings: 1 << 1,
applyWorkingColorSpaces: 1 << 2,

If we add the case of 1 << 1 to the exceptions, exactly one third of all warnings in our test database disappear, all of which are guaranteed to be false, except for the single real case shown at the beginning. In other words, implementing an exception for 1 << 1 improves this rule by a third.

Unsound static analysis

Our development team follows a deliberate approach to warning reliability: we'd rather limit the number of warnings than risk flooding users with noise. It's called an unsound strategy. Here's a quote from our article on taint analysis:

There are sound and unsound static analysis strategies. Usually, the analyzer operates with an unsound strategy and issues warnings only if it can prove an error exists. Under this strategy, the example above won't trigger a warning about the array index out of bounds.

The sound strategy follows the opposite principle: the analyzer issues a warning if it can't prove the absence of an error. The main problem with this strategy is the high number of false positives.

To keep the analyzer from generating hundreds or thousands of false positives, we have to delve into existing approaches and make heuristic exceptions for them. That's how the exception for 1 << 1 made its way into V7001, even though it meant sacrificing a valid warning.

Why not make a more precise exception?

We could try to design something brighter. For example, checking whether there are any other bit flags nearby. But what does nearby mean for the static code analyzer? The analyzer works with a syntax tree, and we could try searching for neighbors within the same enumeration:

But, first, it's easy to trick such heuristics if we:

add an extra node to the tree (a function call, an arithmetic expression, etc.);
change the order of flag declarations;
store the flags in temporary variables.

In each of these cases, the analyzer will either fail to detect the actual error or start generating false positives again, returning to the very problem we were trying to solve.

Second, note that the above warnings appeared in three different contexts:

in enum;
in the initialization of a field within an object expression;
in constant variables.

And that's not counting exotic scenarios like bit flags stored in class fields. There are many such cases, especially in JavaScript/TypeScript, and they're very easy to overlook.

Third, even if we manage to cover all of them at the cost of significantly bloating the code for the rule, there is no guarantee that the heuristics won't deprecate with any future language update. After all, new syntax constructs can simply break it.

So yes, sometimes we have to make a tough call and sacrifice a good warning in favor of a better analyzer's reliability. Plus, this case gave us the idea to create a separate diagnostic rule for identifying errors in bit flag definition :)

Afterword

I hope this gave you a peek into the day-to-day work of developing static analyzers and maybe shed some light on how such tools evolve, and on the compromises that come with improving them. If you've ever faced similar dilemmas in software development, feel free to share them in the comments—I'd love to hear your stories :)

To stay updated on new articles about code quality, you can subscribe to our monthly newsletter or follow my personal blog.

Let's make a programming language. AST

Unicorn Developer — Thu, 04 Jun 2026 12:10:46 +0000

We're continuing our webinar series on building your own programming language in C++!

In the previous part, we created a parser that analyzes code and outputs parsing results to the console. Now, it's time for the next important step—building an AST (Abstract Syntax Tree).

An AST is a structured representation of code that makes further analysis, transformations, and execution possible. In this webinar, you will learn how ASTs work, how to build them step by step, and how to create a printer that makes parsed code much easier to visualize and inspect.

This session will lay the groundwork for everything that comes next in our language implementation journey—semantic analysis, evaluation, and beyond.

The speaker, Yuri Minaev, is an experienced C++ developer and static analyzer architect at PVS-Studio. He's hosted every session in the series and is happy to share his insights on language inner workings along the way.

Join us live to dive deeper into compiler design, ask your questions, and build a programming language from scratch together.

The series is aimed at developers who want to go beyond just using languages and start understanding how they're built. Whether you've been with us from the beginning or are jumping in now, this is a great place to start.

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

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 June 26, 1:00 PM UTC+1

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

Bugs and suspicious code fragments in .NET 10

Unicorn Developer — Wed, 03 Jun 2026 14:55:19 +0000

A little over six months ago, .NET 10 was released. Have any defects remained in the project's source code after all these months? Let's try to find the answer to this question. Enjoy the article!

The new version brings a lot of changes: performance improvements, library updates, new APIs, and further enhancements to the compiler and runtime. However, as experience shows, even code in projects of this level can contain errors.

So, we checked the .NET 10 source code (version 10.0.8) using PVS-Studio static analyzer.

During the analysis, we found multiple suspicious code fragments, potential bugs, and some curious snippets worth the developers' attention. In this article, we'll go over the most exciting warnings the analyzer has issued.

As mentioned earlier, quite some time has passed since the release of .NET 10. However, a quick refresher on the new features wouldn't hurt:

Before we dive into the .NET 10 code, I'd like to mention that PVS-Studio continues to expand the list of supported languages. You can now try the analyzers for Go, JavaScript, and TypeScript through the early access program. Sign up here.

Let's dig into the code!

Always false

Code snippet 1

public static void ReflectionWriteValue(....)
{
  ....
  if (memberValue == null)                                      // <=
  {
    context.WriteNull(xmlWriter,
                    memberType, 
                    DataContract.IsTypeSerializable(memberType));
  }
  else
  {
    PrimitiveDataContract? primitiveContract = ....;
    if (   primitiveContract != null 
        && primitiveContract.UnderlyingType != Globals.TypeOfObject 
        && !writeXsiType)
    {
      primitiveContract.WriteXmlValue(xmlWriter, memberValue, context);
    }
    else
    {
      if (   memberValue == null                                // <=
          && (   memberType == Globals.TypeOfObject
              || (originValueIsNullableOfT && memberType.IsValueType)))
      {
        context.WriteNull(xmlWriter,
                          memberType,
                          DataContract.IsTypeSerializable(memberType));
      }
      else
      {
        ReflectionInternalSerialize(xmlWriter,
                                    context,
                                    memberValue!,
                                    memberValue!.GetType()
                                               .TypeHandle
                                               .Equals(memberType.TypeHandle),
                                    writeXsiType, 
                                    memberType,
                                    originValueIsNullableOfT);
      }
    }
  }
  ....
}

PVS-Studio warning: V3022 Expression 'memberValue == null && (memberType == Globals.TypeOfObject || (originValueIsNullableOfT && memberType.IsValueType))' is always false. ReflectionClassWriter.cs 94

Take a look at the top-level if statement that checks memberValue for null. As a result, in the else block of this if statement, the memberValue variable isn't null. However, this code block contains a check:

if (   memberValue == null 
    && (   memberType == Globals.TypeOfObject
        || (originValueIsNullableOfT && memberType.IsValueType)))

This condition is always false because the memberValue == null check is an operand of the && operator.

Precedence error

Code snippet 2

protected override string GetName(NodeFactory factory)
{
  return   "Reflectable delegate type: " 
         + _delegateType?.ToString() ?? "All delegates";
}

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. ReflectedDelegateNode.cs 38

Quite often, developers forget that the ?? operator has one of the lowest precedence levels. This may cause issues affecting program logic. Fortunately, the logic in this example remains intact, but the issue still exists. If the delegateType field is null when the GetName method executes, instead of the expected message "Reflectable delegate type: All delegates" we will get "Reflectable delegate type: ". This happens because the + operator has higher precedence than ??. To fix the issue, wrap part of the expression in parentheses:

"Reflectable delegate type: " + (_delegateType?.ToString() ?? "All delegates");

They mixed them up

Code snippet 3

public ISymbolNode GenericLookupHelper(
    CORINFO_RUNTIME_LOOKUP_KIND runtimeLookupKind,
    ReadyToRunHelperId helperId,
    object helperArgument,
    GenericContext methodContext)
{
  switch (helperId)
  {
    case ReadyToRunHelperId.TypeHandle:
      return GenericLookupTypeHelper(
          runtimeLookupKind,
          ReadyToRunFixupKind.TypeHandle,
          helperArgument,
          methodContext);

    case ReadyToRunHelperId.MethodHandle:
      return GenericLookupMethodHelper(
          runtimeLookupKind,
          ReadyToRunFixupKind.MethodHandle,
          (MethodWithToken)helperArgument,
          methodContext);

    case ReadyToRunHelperId.MethodEntry:
      return GenericLookupMethodHelper(
          runtimeLookupKind,
          ReadyToRunFixupKind.MethodEntry,
          (MethodWithToken)helperArgument,
          methodContext);

    case ReadyToRunHelperId.MethodDictionary:  // <=
      return GenericLookupMethodHelper(
          runtimeLookupKind,
          ReadyToRunFixupKind.MethodHandle,    // <=
          (MethodWithToken)helperArgument,
          methodContext);

    case ReadyToRunHelperId.TypeDictionary:
      return GenericLookupTypeHelper(
          runtimeLookupKind,
          ReadyToRunFixupKind.TypeDictionary,
          (TypeDesc)helperArgument,
          methodContext);

    case ReadyToRunHelperId.VirtualDispatchCell:
      return GenericLookupMethodHelper(
          runtimeLookupKind,
          ReadyToRunFixupKind.VirtualEntry,
          (MethodWithToken)helperArgument,
          methodContext);

    case ReadyToRunHelperId.FieldHandle:
      return GenericLookupFieldHelper(
          runtimeLookupKind,
          ReadyToRunFixupKind.FieldHandle,
          (FieldWithToken)helperArgument,
          methodContext);

    default:
      throw new NotImplementedException(helperId.ToString());
  }
}

PVS-Studio warning: V3139 Two or more case-branches perform the same actions. ReadyToRunSymbolNodeFactory.cs 583

The code contains many similar operations written in the same pattern, so an error could easily have slipped in. If helperId equals ReadyToRunHelperId.MethodDictionary, then ReadyToRunFixupKind.MethodHandle is passed to the GenericLookupMethodHelper method. This doesn't look quite right, since the ReadyToRunFixupKind enum already includes a MethodDictionary element. It seems that GenericLookupMethodHelper should receive it when helperId matches ReadyToRunHelperId.MethodDictionary.

Code snippet 4

partial class MutableModule
{
  ....

  public int CompareTo(MutableModule other)
  {
    return _index.CompareTo(_index);
  }
}

PVS-Studio warning: V3062 An object '_index' is used as an argument to its own method. Consider checking the first actual argument of the 'CompareTo' method. MutableModule.Sorting.cs 19

In the CompareTo method, the _index field is compared to itself. Most likely, other._index should be passed as an argument.

Code snippet 5

public void ComputeReturnValueTreatment(....)
{
  ....

  if (descriptor.passedInRegisters)
  {
    if (descriptor.eightByteCount == 1)
    {
      if (descriptor.eightByteClassifications0 
                == SystemVClassificationType.SystemVClassificationTypeSSE)
      {
        // Structs occupying just one eightbyte are treated as int / double
        fpReturnSize = sizeof(double);
      }
    }
    else
    {
      // Size of the struct is 16 bytes
      fpReturnSize = 16;
      // The lowest two bits of the size encode 
      // the order of the int and SSE fields
      if (descriptor.eightByteClassifications0                            // <=
               == SystemVClassificationType.SystemVClassificationTypeSSE)
      {
        fpReturnSize += 1;
      }

      if (descriptor.eightByteClassifications0                            // <=
               == SystemVClassificationType.SystemVClassificationTypeSSE)
      {
        fpReturnSize += 2;
      }
    }

    break;
  }

  ....
}

PVS-Studio warning: V3029 The conditional expressions of the 'if' statements situated alongside each other are identical. Check lines: 364, 369. TransitionBlock.cs 364

The analyzer reported a series of if statements with identical conditions. Indeed, descriptor.eightByteClassifications0 is compared twice with SystemVClassificationType.SystemVClassificationTypeSSE. It seems likely that the check is incorrect in one of the cases, given the presence of the eightByteClassifications1 field in descriptor. Most likely, the field should be used in one of the checks.

Are you sure it's not null?

Code snippet 6

public static bool SubstEqualTypeArrays(TypeArray taDst,
                                        TypeArray taSrc,
                                        TypeArray typeArgsCls,
                                        TypeArray typeArgsMeth)
{
  // Handle the simple common cases first.
  if (taDst == taSrc || (taDst != null && taDst.Equals(taSrc))) // <=
  {
    // The following assertion is not always true and indicates a problem where
    // the signature of override method does not match the one inherited from
    // the base class. The method match we have found does not take the type
    // arguments of the base class into account. 
    // So actually we are not overriding the method that we "intend" to.
    // Debug.Assert(taDst == SubstTypeArray(taSrc,
                                            typeArgsCls,
                                            typeArgsMeth,
                                            grfst));
    return true;
  }
  if (taDst.Count != taSrc.Count)                               // <=
    return false;
  if (taDst.Count == 0)
    return true;

  var ctx = new SubstContext(typeArgsCls, typeArgsMeth, true);
  if (ctx.IsNop)
  {
    return false;
  }

  for (int i = 0; i < taDst.Count; i++)
  {
    if (!SubstEqualTypesCore(taDst[i], taSrc[i], ctx))
      return false;
  }

  return true;
}

PVS-Studio warning: V3125 The 'taDst' object was used after it was verified against null. Check lines: 354, 344. TypeManager.cs 354

In the first if statement, the taDst parameter is checked for null, suggesting that it may be null. However, in the next if statement, the taDst parameter is dereferenced without being checked: taDst.Count. If taDst is null and taSrc isn't, then a NullReferenceException will be thrown.

Code snippet 7

internal void WriteXmlnsAttribute(XmlDictionaryString ns)
{
  if (dictionaryWriter != null)
  {
    if (ns != null) 
      dictionaryWriter.WriteXmlnsAttribute(null, ns);
  }
  else
    WriteXmlnsAttribute(ns.Value);
}

PVS-Studio warning: V3125 The 'ns' object was used and was verified against null in different execution branches. Check lines: 71, 67. XmlWriterDelegator.cs 71

This issue is similar to the previous one. In the then block of the first if statement, the ns parameter is checked for null before being used. This check is missing from the else block. The ns parameter may be related to the dictionaryWriter field, meaning we don't need to check ns for null if dictionaryWriter is null. However, we couldn't find any evidence of this.

It currently looks like if dictionaryWriter and ns are null, accessing ns.Value will throw a NullReferenceException.

Code snippet 8

private struct ModuleAndIntValueKey : IEquatable<ModuleAndIntValueKey>
{
  public bool Equals(ModuleAndIntValueKey other) => 
         IntValue == other.IntValue 
      && (   (Module == null && other.Module == null) 
          ||  Module.Equals(other.Module));
}

PVS-Studio warning: V3125 The 'Module' object was used after it was verified against null. Check lines: 180, 180. ReadyToRunCodegenNodeFactory.cs 180

When comparing objects of the ModuleAndIntValueKey type, their Module fields are checked:

(Module == null && other.Module == null) ||  Module.Equals(other.Module)

If Module is null and other.Module isn't, a NullReferenceException will be thrown. Since the left operand of the || operator is false, the condition will be evaluated further, resulting in the dereferencing of Module when Equals is called.

To fix this, we'll add a null check before accessing Module.

Code snippet 9

public bool IsInheritanceChainLayoutFixedInCurrentVersionBubble(TypeDesc type)
{
  // This method is not expected to be called for value types
  Debug.Assert(!type.IsValueType);

  if (type.IsObject)
    return true;

  if (!IsLayoutFixedInCurrentVersionBubble(type))
  {
    return false;
  }

  type = type.BaseType;

  if (type != null)
  {
    return false;

    while (!type.IsObject && type != null)
    {
      if (!IsLayoutFixedInCurrentVersionBubble(type))
      {
        return false;
      }
      type = type.BaseType;
    }
  }

    return true;
}

PVS-Studio warning: V3027 The variable 'type' was utilized in the logical expression before it was verified against null in the same logical expression. ReadyToRunCodegenCompilation.cs 596

In the while statement, the IsObject property of the type variable is accessed first, and then type is checked for null. Such a check seems ineffective. If type is null, the NullReferenceException is thrown.

To fix this, we need to either swap the null check and the property access, or, if type is never null, remove the null check.

Tricky comparison

Code snippet 10

public class PropertyPseudoDesc : TypeSystemEntity
{
  ....

  public static bool operator ==(PropertyPseudoDesc a, PropertyPseudoDesc b) 
              => a._type == b._type && a._handle == b._handle;

  ....
}

PVS-Studio warning: V3115 Passing 'null' to '==' operator should not result in 'NullReferenceException'. PropertyPseudoDesc.cs 89

If one of the operands is null when comparing objects of the PropertyPseudoDesc type, the NullReferenceException will be thrown. To avoid this, we need to check whether the operand fields are null before accessing them.

Conclusion

The .NET 10 check showed us that even six months after the release, the project still contains bugs and code snippets that could cause issues. Some of them are classic errors: ambiguous conditions, redundant checks, potential NREs, and confusing logic branches. Such issues are difficult to spot during a quick code review, especially in a large, platform-level codebase.

Every year, we check the latest .NET version:

We also frequently post checks of other popular projects. To stay up to date on new checks, subscribe to our newsletter.

If you'd like to try out PVS-Studio yourself, click the link!

Real-world C++ projects built with GenAI: do they exist?

Unicorn Developer — Fri, 29 May 2026 12:27:13 +0000

To keep PVS-Studio sharp against whatever new patterns of bugs vibe coding introduces, I've been hunting for real open-source C++ projects built this way. Turns out finding them is the hard part.

What I do keep finding is things like enhance-client generated for $15. Not even worth looking at seriously. You can tell from the .obj, .iobj, .ipdb files, and other junk sitting in the repo that whoever wrote this wasn't too familiar with the basics. The project won't compile for various reasons, one being a broken bytes.hpp that just cuts off in the middle of an array.

Fix it up just enough to compile and you'll start finding gems like this:

void enhance::modules::autototem::run()
{
  ....
  auto env = enhance::instance->get_env();
  if (!env)
  {
    env->DeleteLocalRef(player);
    return;
  }
  ....
}

The PVS-Studio warning: V522 [CWE-476, CERT-EXP34-C, SEC-NULL] Dereferencing of the null pointer 'env' might take place. autototem.cpp 757

A clear null pointer dereference.

Or meaningless comparisons of an int value with the literal 0.1f:

int sdk::minecraft_client::get_attack_cooldown() { .... }

void enhance::modules::shield_breaker::run()
{
  ....
  if (sdk::instance->get_attack_cooldown() > 0.1f)
  ....
}

The PVS-Studio warning: V674 [CWE-682, CERT-FLP36-C] The '0.1f' literal of the 'float' type is compared to a value of the 'int' type. shield_breaker.cpp 628

These blunders aren't really worth going through one by one.

Sure, you could ask "what do you expect from a $15 project?" and you'd have a point. But that's all I ever find. What I'm looking for is a solid open-source C++ project where GenAI was a big part of the development process. So far, nothing like that. At this point, vibe coding feels like it exists mostly as a buzzword, while real vibe-coded C++ projects simply don't. Or are they hiding somewhere, too ashamed to be seen? :)

If you know of any C++ projects built with GenAI that are worth looking at, I'd really appreciate a link in the comments.

Earlier blog posts on some small vibe-coded projects:

Double AI agents: What's hiding in your Golang code

Unicorn Developer — Thu, 28 May 2026 12:33:33 +0000

Today, almost everyone has got a taste of the vibe code, and some have gone a step further by setting up their own AI agents for projects. Meanwhile, headlines are buzzing about how some AI agents deleted databases with all backups. Now, we look at the source code for projects that are related in some way to agent-based development.

Intro

Agent-based development and various AI solutions are becoming increasingly common in software development. We took PVS-Studio Go analyzer and set it up to inspect AI-driven projects, like different on-premise AI models, load balancers, subscription proxy services, and others. These aren't just random projects; they're actively used and in demand.

Want to try our Go analyzer on your projects? Join the Early Access Program. The EAP is currently available for JavaScript, TypeScript, and Go.

As said one wise man, let's make hay while the sun shines. In our case, go ahead with the project analysis.

Project analysis

New-api

And we start with New API, an LLM gateway and AI asset management system that manages a plethora of API keys from various providers through a single gateway. This case shows that even a large-scale and popular project like this one (33,000 GitHub stars) can contain bugs and suspicious code.

Commit: 22b6b16.

func GetChannel(group string, model string, retry int) (*Channel, error) {
  var abilities []Ability

  var err error = nil
  channelQuery, err := getChannelQuery(group, model, retry)
  if err != nil {
    return nil, err
  }
  if common.UsingSQLite || common.UsingPostgreSQL {
    err = channelQuery.Order("weight DESC").Find(&abilities).Error
  } else {
    err = channelQuery.Order("weight DESC").Find(&abilities).Error
  }
  ....
}

The PVS-Studio warning: V8005 The 'then' statement is equivalent to the 'else' statement. ability.go 114

The analyzer detected that the if statement with the common.UsingSQLite || common.UsingPostgreSQL condition may be meaningless, since the same code is executed in both the then and else clauses.

PVS-Studio found a similar issue in the following code snippet:

func StreamResponseClaude2OpenAI(....) .... {
  ....
  if claudeResponse.Type == "message_start" {
    ....
  } else if claudeResponse.Type == "content_block_start" {
    ....
  } else if claudeResponse.Type == "content_block_delta" {
    ....
  } else if claudeResponse.Type == "message_delta" {
    ....
  } else if claudeResponse.Type == "message_stop" {
    return nil
  } else {
    return nil
  }
  ....
}

The PVS-Studio warning: V8005 The 'then' statement is equivalent to the 'else' statement. relay-claude.go 474

It looks like an error, but we can't say for sure just yet—maybe the logic for claudeResponse.Type == "message_stop" hasn't been implemented yet.

Tau

Now PVS-Studio inspects the Tau project, an open-source platform for building self-hosted cloud infrastructures.

Commit: 1e5036f.

func (p *pluginInstance) makeFunc(....) reflect.Value {
  ....
  _out := make([]reflect.Value, len(cOut))
  for idx := 0; idx < len(cOut); idx++ {
    switch retTypes[idx] {
    case vm.I32Type:
      _out[idx] = reflect.ValueOf(int32(cOut[idx]))
    case vm.I64Type:                                            // <=
      _out[idx] = reflect.ValueOf(int64(cOut[idx]))
    case vm.F32Type:
      _out[idx] = reflect.ValueOf(math.Float32frombits(uint32(cOut[idx])))
    case vm.I64Type:                                            // <=
      _out[idx] = reflect.ValueOf(math.Float64frombits(cOut[idx]))
    }
  }
  ....
}

The PVS-Studio warning: V8010 Two or more case branches have equivalent expressions. instance.go 93

The same I64Type expression is used in multiple case statements, which makes no sense because the code inside the second case will never be executed. And most likely, F64Type should be used instead of the second I64Type:

switch retTypes[idx] {
  case vm.I32Type:
    _out[idx] = reflect.ValueOf(int32(cOut[idx]))
  case vm.I64Type:
    _out[idx] = reflect.ValueOf(int64(cOut[idx]))
  case vm.F32Type:
    _out[idx] = reflect.ValueOf(math.Float32frombits(uint32(cOut[idx])))
  case vm.F64Type: 
    _out[idx] = reflect.ValueOf(math.Float64frombits(cOut[idx]))
 }

We found a similar error pattern in the code of the popular ads blocker AdGuardHome. We even wrote an article: Go vet can't go. How PVS-Studio analyzes Go projects.

Sub2api

Move on to the proxy server for AI services, Sub2API.

Commit: 0f03393.

func cleanJSONSchemaRecursive(value any) any {
  ....
  if hasKey(schemaMap, "properties") {
    schemaMap["type"] = "object"
  } else {
  // 默认为 string ? or object? Gemini 通常需要明确 type
    schemaMap["type"] = "object"
  }
  ....
}

The PVS-Studio warning: V8005 The 'then' statement is equivalent to the 'else' statement. schema_cleaner.go 310

There may be an error in either the then or else branch of this code snippet, as both sections are identical. At best, the if statement is redundant and only makes the code more complicated.

Look at another code fragment:

func classifyOpsPhase(errType, message, code string) string {
  ....

  switch errType {
  case "authentication_error":
    return "auth"
  case "billing_error", "subscription_error":
    return "request"                                  // <=         
  case "rate_limit_error":
    if .... {
      return "request"
    }
    return "upstream"
  case "invalid_request_error":
    return "request"                                  // <=
  case "upstream_error", "overloaded_error":
    return "upstream"
  case "api_error":
    if strings.Contains(msg, opsErrNoAvailableAccounts) {
      return "routing"
    }
    return "internal"
  default:
    return "internal"
  }
}

The PVS-Studio warning: V8009 Two or more case branches perform the same actions. ops_error_logger.go 1125

The analyzer found the switch branches with identical body. The diagnostic rule is triggered quite often, since some cases require identical executable code, and some developers prefer not to use commas to list conditions.

The first case, which returns the request value, contains several expressions: case "billing_error", "subscription_error". Here, it'd make sense to write the case "invalid_request_error" expression from the second case after a comma, since they should always result in the same outcome.

We also couldn't ignore the following case:

case "rate_limit_error":
    if .... {
      return "request"
    }
    return "upstream"

The request value can be returned, but we can see there is additional handling. Maybe the second case, which has the same body, should also include some extra processing, but it's hard to tell from the context what exactly should be there, so the analyzer highlights the strange code fragment.

We can notice the same case in the classifyopsErrorSource function:

func classifyOpsErrorSource(phase string, message string) string {
  // Standardized sources: client_request|upstream_http|gateway
  switch phase {
  case "upstream":
    return "upstream_http"
  case "network":
    return "gateway"                                  // <=
  case "request", "auth":
    return "client_request"
  case "routing", "internal":
    return "gateway"                                  // <=
  default:
    if strings.Contains(strings.ToLower(message), "upstream") {
      return "upstream_http"
    }
    return "gateway"
  }
}

The PVS-Studio warning: V8009 Two or more case branches perform the same actions. ops_error_logger.go 1220

On one hand, merging case "routing", "internal" and case "network" may not be a bad idea, but it looks like some code is missing here, just as in the default branch.

Photoprism

PhotoPristm is an open-source, self-hosted photo management app. This project is interesting due to its built-in AI capabilities and a REST API, which allow agents to manage the photo library.

Commit: 93bb435.

func (c *opticsClusterer) extract() {
  ....
  switch {
  case math.Abs(d) <= c.xi:
    cs = areas[j].start
    ce = ue
  case d > c.xi:
    for k := areas[j].end; k > areas[j].end; k-- {                    // <=
      if ....{
        cs = k
        break
      }
    }
    ce = ue
  default:
    cs = areas[j].start
    for k := i; k < e; k++ {
      if ....{
        ce = k
        break
      }
    }
  }
  ....
}

The PVS-Studio warning: V8016 The loop condition will never be met. Inspect initial and final values in the 'for' loop. optics.go 321

The analyzer warns that the for condition will never be executed, since the start and end values are both equal to areas[j].end. This is most likely a typo, and the condition should be as follows:

for k := areas[j].end; k > areas[j].start; k-- {
  ....
}

Axonhub

And here's another proxy, Axonhub.

Commit: bfc11e01.

func AggregateStreamChunks(....) ([]byte, llm.ResponseMeta, error) {
  ....

  if event.Delta.Thinking != nil {
    if contentBlocks[index].Type == "thinking" {
      if contentBlocks[index].Thinking == nil {
        contentBlocks[index].Thinking = lo.ToPtr("")
      }

      *contentBlocks[index].Thinking += *event.Delta.Thinking
    } else {
      // Convert to thinking block if it's not already
      contentBlocks[index].Type = "thinking"
      contentBlocks[index].Thinking = event.Delta.Thinking
    }
  }

  if event.Delta.Signature != nil {                                      // <=
    // Handle signature delta - append to thinking block signature
    if contentBlocks[index].Type == "thinking" {
      if event.Delta.Signature != nil {                                  // <=
        if contentBlocks[index].Signature == nil {
          contentBlocks[index].Signature = event.Delta.Signature
        } else {
          contentBlocks[index].Signature = lo.ToPtr(....)
        }
      }
    } else {
      // Convert to thinking block if it's not already
      contentBlocks[index].Type = "thinking"
      contentBlocks[index].Signature = event.Delta.Signature
    }
  }

  ....
}

The PVS-Studio warning: V8020 Recurring check. The 'event.Delta.Signature != nil' condition was already verified on line 96. aggregator.go 96

The analyzer detected a recursive check, event.Delta.Signature != nil. Double check is meaningless because it's always true.

LocalAI

Now it's a LocalAI turn, an open-source AI engine that allows running any model.

Commit: dd8e74a.

func (r *RunCMD) Run(ctx *cliContext.Context) error {
  ....

  if r.DisableMetricsEndpoint {
    opts = append(opts, config.DisableMetricsEndpoint)
  }

  if r.DisableRuntimeSettings {
    opts = append(opts, config.DisableRuntimeSettings)
  }

  if r.EnableTracing {
    opts = append(opts, config.EnableTracing)
  }

  if r.EnableTracing {
    opts = append(opts, config.EnableTracing)
  }
  opts = append(opts, config.WithTracingMaxItems(r.TracingMaxItems))

  ....
}

The PVS-Studio warning: V8017 The conditions of the 'if' statements situated alongside each other are equivalent. Check lines: 158, 162. run.go 158

We can see that the Run function duplicates strings:

if r.EnableTracing {
    opts = append(opts, config.EnableTracing)
  }

This is most likely a bug that may cause opts = append(opts, config.EnableTracing) to be executed twice when r.EnableTracing is set to true.

It's also possible that the second r.EnableTracing and config.EnableTracing should be something else, and some of the functionality is simply missing. Maybe this is a copy-pasting case.

Let's move on to the next warning:

func parseXMLWithFormat(s string, format *XMLToolCallFormat) (....) {
  ....

  for _, match := range toolCallMatches {
    if len(match) < 3 {
      continue
    }

    ....

    var functionContent string
    if len(match) >= 3 {
      if format.ToolSep == "" && format.KeyStart != "" {
        functionContent = match[2]
      } else {
        functionContent = match[2]
      }
    }
    ....
  }
  ....
}

The PVS-Studio warning: V8005 The 'then' statement is equivalent to the 'else' statement. parse.go 902

The then and else blocks are identical, so there's no point in using if here.

Most likely, this is a copy-paste error, where the developers forgot to update the index in the second line: functionContent = match[2].

As a result, V8005 immediately generated three warnings for three similar fragments:

func ChatEndpoint(....) echo.HandlerFunc {
  ....
  if len(cleanedContent) > len(lastEmittedCleanedContent) &&  
    strings.HasPrefix(cleanedContent, lastEmittedCleanedContent) {
    deltaContent = cleanedContent[len(lastEmittedCleanedContent):]
    lastEmittedCleanedContent = cleanedContent
  } else if cleanedContent != lastEmittedCleanedContent {
    // If cleaned content changed but not in a simple append, 
    // extract delta from cleaned content
    // This handles cases where thinking tags are removed mid-stream
    if lastEmittedCleanedContent == "" {
      deltaContent = cleanedContent                             // <=
      lastEmittedCleanedContent = cleanedContent                // <=
    } else {
      // Content changed in non-append way, use the new cleaned content
      deltaContent = cleanedContent                             // <=
      lastEmittedCleanedContent = cleanedContent                // <=
    }
  }
  ....
}

The PVS-Studio warning: V8005 The 'then' statement is equivalent to the 'else' statement. chat.go 85

And here we go again: the then and else blocks contain the same code. However, this time there are three such blocks. This suggests that the code may have been generated and then pulled into other functions.

Outro

That's all for now. If you're interested in project checks focused on AI and agent-based development, feel free to let us know in the comments :)

PVS-Studio has recently launched the Early Access Program for new analyzers, and you can join! EAP is currently available for JavaScript, TypeScript, and Go.

Want to check your project using PVS-Studio? Grab a trial and give it a try!

Take care of yourself and your code!

Bugs not dead: How to catch bugs in game code

Unicorn Developer — Thu, 28 May 2026 09:37:24 +0000

Bugs, crashes, glitches... Game development is full of them, and even experienced teams run into issues. But while no game is perfect, that doesn't mean we should stop chasing better quality.

In this live session, we'll look at why even seasoned game development teams make mistakes and how you can reduce the number of issues in your own projects.

What's the talk about?

The speaker, Gleb Aslamov, developer advocate and static analyzer developer at PVS-Studio, will walk you through common and less obvious reasons behind code errors, share real-world bug examples from actual game projects, discuss development practices that help prevent bugs before release, and demonstrate tools designed to catch those issues early.

Gleb will show some amusing bug examples from projects like osu!, GZDoom, and SanAndreas Unity. The discussion will cover how code reviews, testing, and CI/CD, combined with profilers, dynamic analyzers, and static analyzers, can help detect issues long before players ever encounter them.

Also, expect to see static analysis in action, including warnings that reveal performance-sensitive issues and other hidden problems in game code.

When?

Mark your calendar for June 2, 2026, at 1:00 PM UTC+1.

Join the live talk and learn how to make your game code more reliable—one bug at a time.

P.S. And don't forget to check your inbox to confirm the registration!

C++ digest: News, helpful resources, & your own programming language as bonus

Unicorn Developer — Tue, 26 May 2026 12:44:29 +0000

While the industry debates memory safety, the ISO committee and developers continue shaping the future of a much-loved language, we've gathered the most exciting recent events from the C++ world, along with some useful resources.

The road to C++26: contracts and reflection

The ISO Committee has finished the technical work on C++26. During a series of meetings, the committee refined the upcoming standard's feature set, exceeding many expectations. Key additions include:

compile-time reflection, which enables a program to describe its own structure and generate code at compile time;
std::execution, a universal framework for asynchronous execution, concurrency, and parallelism;
the pre, post, and contract_assert contracts, which enable developers to define preconditions, postconditions, and assertions directly in function declarations;
new parallel algorithms, #embed for binary data, better metaprogramming capabilities, and many other important updates.

Both GCC and Clang compilers have already implemented most C++26 features during the standardization process, and they'll soon appear in other compilers as well.

Security profiles

Efforts to improve security in the upcoming C++29 continue. Bjarne Stroustrup is actively promoting the concept of C++ Profiles. They're sets of additional rules that developers can apply in their code to ensure security.

Profiles help prevent common issues, such as null pointer dereferences or buffer overflows. They also provide a unified foundation for improving safety without sacrificing the core strengths of C++.

The LLVM 22 update

This spring brought a new release of LLVM 22.1. This update brings a wide range of changes: supporting different architectures and adding advanced memory management tools. Key highlights include:

support for new processors (Intel Nova Lake, Wildcat Lake, RISC-V, and other architectures);
support for new C++26 features;
advanced memory control tools (special allocation tagging tokens for memory tracking).

You can find the full list of updates on the official website.

Articles

Rust vs C++: Competition or Evolution in Systems Programming for 2026

C and C++ form the foundation of modern software. Operating systems, databases, game engines, and compilers—they all trace their origins back to these languages. Their speed, power, and reliability made them the choice of many. Today, developers have another choice: Rust. This language incorporates the strengths of C++ and addresses some of its issues like memory safety and undefined behavior. So, what's the best option for a developer? The article author explains in detail cases where Rust or C++ has benefits and also describes the pros and cons of these languages.

How far does lookup see in C++?

Placing functions near the types they're intended for is a good practice in C++. However, to properly apply this approach , one should understand how the name lookup mechanisms work as well as where to place functions without violating the language rules. The article author covers the concept of name lookup and explores an argument-dependent lookup (ADL) in particular.

Silent foe or quiet ally: Brief guide to alignment in C++

Have you ever wondered how data is stored in computer memory? Each variable occupies space in memory as a sequence of bytes at a specific address. However, access to this data is winding: data first gets into the fast cache, which exchanges data blocks with RAM.

In this series of articles, the author carefully explains the data alignment mechanism. The second part is here. And here's the third one.

Let's check vibe code that acts like optimized C++ one but is actually a mess

Vibe coding is a hot topic these days. In the article, the author uses a small project called Markus as an example to explain why it's important to understand AI-generated code and be able to see what lies beneath a program's elegant syntax. What do you think of vibe coding? Let us know in the comments!

To stay up to date on the latest C++ 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!

Talks

Creator of C++: Bell Labs, Negative Overhead Abstraction, Mistakes | Bjarne Stroustrup — Ryan Peterman

In this talk, Bjarne Stroustrup, creator of C++ and former Bell Labs researcher, reflects on the origins of C++, tracing its evolution from Simula to a system built on C. He discusses the C++ standards committee, memory safety, AI writing code, zero-overhead abstraction, and what he wishes he'd fought harder for from the start.

Lightning Talk: Learning C++ Through Writing Coding Questions — CppCon 2025

CppCon has shared talks from the last event. In this talk, the speaker explains why creating custom exercises for employee training is one of the best ways to master the knowledge of the modern C++ standards. He also discusses how to go from understanding a language feature to explaining it with code example and implementing it in a project.

Lightning Talk: A C++20 Modules Performance Field Report — Tyler Drake — CppCon 2025

At CppCon 2025, Tyler Drake shared an interesting field report. He wrapped "header-heavy" third-party libraries into custom C++20 modules. The result: full build time on his laptop dropped by 41.5%, and incremental builds were cut in half—down to just 1 second. A compelling argument for anyone still hesitant to adopt modules due to legacy dependencies.

Podcasts

GPU Programming and HLSL with Chris Bieneman — CppCast 407 — C++Weekly Ep 533 — C++ Weekly With Jason Turner

Jason Turner, Mathieu Ropert, and Chris Bieneman talk about the history of GPU shading languages from DirectX assembly in the early 2000s through today, why HLSL is gradually becoming more C++-like (templates, structs, auto), and where it deliberately draws the line. They discuss current industry trends around AI-generated code, and the difficulties of maintaining floating-point consistency across platforms.

P.S. When choosing content for the digest, we noticed that they also mentioned our article on analyzing vibe-coded projects. Thank you for your kind words about PVS-Studio, it means a lot to us to hear such positive feedback from you.

Sea of Thieves — Keeping Games Up to Standard — Keith Stockdale — CppCast 406 / C++Weekly 529

Here's another episode of CppCast with Jason Turner and Mathieu Ropert. Keith Stockdale, senior software engineer at Rare, brings up the topic about challenges of maintaining large, long-term C++ codebases in game dev. The talk covers modern C++ standards, the effect of compiler-specific code on portability, and the practical realities of upgrading systems such as Unreal Engine in professional studio environments.

Measure Twice, Optimize Once — Two's Complement Podcast

In this podcast episode, Ben Rady and Matt Godbolt talk about performance optimization: benchmarks and microbenchmarks, real performance problems in software systems. They also discuss how to measure performance before optimization and how to understand profiling noise.

Episode 286: GPU Profiling with NVIDIA Nsight Compute (NCU) — ADSP: The Podcast

The talk focuses on GPU optimization techniques, profiling tools, and high-performance algorithm design. Marco Salgado explains how GPU workloads often become limited by memory throughput. The speakers examine profiling with NVIDIA Nsight Compute, GPU rotate algorithms, and the role of libraries such as NVComp for GPU-based compression. They also discuss how high-level libraries and languages can outperform hand-written low-level implementations by automatically applying optimizations.

A series of talks on how to create your own programming language

C++ is constantly evolving and growing: new useful features appear, making it easier to use, but new challenges also arise. If you want to better understand how any language works, it's worth trying to create your own.

We invite you to watch a series of talks where we create a custom programming language in a live-coding format. Yuri Minaev, experienced C++ developer and architect at PVS-Studio, will guide you through the journey of mastering C++: from implementing a lexer and a recursive descent method to creating your own evaluator. Less boring theory and more actual coding is a great way to boost your programming skills.

Want to learn how to create your own programming language? Follow the link and join new webinars!

Conclusion

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

Don't forget, PVS-Studio stands guard over your codebase. Get the 30-day trial promo code here!

Unity’s AI agent went public: the developers of a static analysis tool on what that means for code quality

Unicorn Developer — Fri, 22 May 2026 14:21:23 +0000

In early May, Unity opened its built-in Unity Agent to all users.

It runs in two modes. In chat mode, the AI assistant suggests improvements to game mechanics and helps track down bugs. In agent mode, it works autonomously: analyzing your project, generating and editing code on its own.

The official demo runs through a workflow: a user builds a game arena, generates a car from reference images, turns it into a playable character, and adds a minigun. The entire thing runs on text prompts, so no code is written manually.

In the post, Unity described it as AI taking over the tedious parts, while developers stay in charge of creative direction.

“Our goal with AI is to help you build better games, faster. Unity AI gives you access to our own in-project agentic assistant, which leverages deep context from your projects and is built specifically for Unity workflows”

The response was split. Some users worry gaming platforms will be flooded with low-effort projects chasing viral trends. But there’s another concern that gets less attention: code quality.

The PVS-Studio team builds a static analysis tool for code quality, reliability, and security. Here’s their comment on the Unity update:

Learn about Medium’s values
“Tools like this are a logical step forward, but their limitations matter too. Generative AI genuinely speeds up development, yet it makes mistakes regularly: wrong logic, unsafe patterns, code that runs but isn’t necessarily safe. The root cause is plain: AI generates code based on probabilities, not strict security requirements.

That’s where static analyzers come in. Not just to catch bugs, but to systematically check for vulnerabilities before anything ships.

PVS-Studio has been used in game development for years, by studios and engine teams alike. Part of what makes it effective on game code is a combination of deep code analysis and built-in annotations for many Unity and Unreal Engine functions and classes. That extra metadata lets the tool warn developers when an API is being used incorrectly.

It also covers optimization. Poor performance hurts players just as much as bugs do. Surely, an AI assistant can also suggest optimizations when prompted, and that’s fine for small projects. But at scale, things slip through: suboptimal ordering of math operations across different data structures, unnecessary allocations, repeated calculations that should be cached.

PVS-Studio currently has 20 Unity-specific diagnostic rules, as well as general diagnostics tuned to account for how Unity scripts actually work.

The broader point: the more AI-generated code enters a codebase, the more you need tooling that filters it. SAST tools become a necessary filter, not an optional one. AI and static analysis aren’t in competition, they’re increasingly paired by necessity. Skip the verification layer, and quality and security will erode as AI usage grows.”

PVS-Studio is a static code analyzer for C, C++, C#, and Java — a SAST tool focused on safety and security defects. Since 2008, it has been used by hundreds of companies worldwide. Over 17 years, the team has reviewed more than 500 open-source projects and written about them extensively: ~1,500 articles published on the PVS-Studio blog.

The analyzer provides more than 1,100 diagnostic rules covering a wide range of error patterns and security defects, and integrates with major IDEs, game engines (Unity, Unreal Engine), build systems, and CI pipelines, including cloud environments. It can operate in air-gapped setups, maps warnings to CWE and SEI CERT, and supports MISRA standards.

PVS-Studio is used across mechanical engineering, medicine, finance, construction, and game development.

Game++. Part 1.2: C++, game engines, and architectures

Unicorn Developer — Thu, 21 May 2026 13:34:13 +0000

AI

Of all the aspects of game development, AI is my favorite topic. Over the past years, I've spent so much time wrestling with mobs that if I had a dollar for every one stuck in a corner, I'd have bought a house by now. First there were lone enemies, then packs of mobs, then coordinated groups sharing behavior trees (BTs).

Turns out, not every game actually needs "smart" AI. That sounds counterintuitive, but half the time, a couple of simple scripts that have enemies yelping "Ouch!" on a timer and blindly charging into walls are more than enough to satisfy players. AI isn't magic—it's just code. If your engine supports if, switch, coroutines, or timers—congrats: you already have AI support. All the "intelligence" is just a bunch of conditions cleverly disguised as brainpower. But when devs want to go "pro", they usually adopt one or more of the approaches below.

...Behavior Trees (BT)

Basically, think of it as a simple priority list: if you are hungry, eat; if you see an enemy, attack; if you are badly injured, flee. Behavior trees (BTs) express decisions as a hierarchy of composite and leaf nodes; each node returns one of three statuses: Success, Failure, or Running.

Composite nodes—Selector, Sequence, and Parallel—control how child nodes run and implement priorities from the top down. A Selector might order branches such as "health below 20% → flee," "enemy in sight → attack," "hunger above 80% → eat," evaluating them in sequence until one succeeds. Leaf nodes (Action, Condition) perform concrete actions or checks. That structure tends to stay readable—the tree mirrors the intended logic— which is why BTs are widely used in games and work well with visual editors and hot reload, letting designers iterate on AI without recompiling. Still, a BT with 500+ nodes can devolve into spaghetti that nobody can follow, not even whoever wrote it.

...GOAP (Goal-Oriented Action Planning)

GOAP-style AI starts from a question like: "I want to kill the player. What should I do?" It doesn't simply run a fixed script; it assembles a plan from the actions that exist in the world and the current state. Elegant? Yes. But rolling your own planner is no small job. You must handle resources, conflicting effects, action costs, cycles in the search space, and more. GOAP fits heavy, systemic games and is common at large studios, yet it costs serious engineering time and a strong team to implement and debug.

Unlike rigid behavior trees or finite state machines, GOAP is largely declarative: you specify actions with preconditions and effects, and the planner searches for a sequence that transforms the current world state into one that satisfies the goal. For a goal such as "kill the player," it might produce something like: acquire a weapon → close with the player → attack. The planner can infer that attacking needs a weapon, getting a weapon may require reaching an armory, and movement depends on being able to move. That yields more natural, adaptive behavior: the NPC can respond to a changing world and replan when conditions shift.

...FSM (Finite State Machine)

This is the classic setup with states and transitions—idle → walk → attack → flee. A finite state machine (FSM) is a simple formal model: an entity is always in exactly one of a finite number of states, and it moves between them according to rules driven by events or conditions. The pattern maps cleanly to character and enemy behavior. A player might use states such as idle, walk, run, jump, attack, or dead; an AI mob might use patrol, pursue, attack, retreat, or take cover. Each state bundles its own logic: animations, audio, physics tuning, and which actions are allowed. Transitions hinge on explicit triggers: input, collisions, health thresholds, distance to a target, so behavior stays predictable and comparatively easy to debug.

...Utility AI

Look at NPC with a handful of possible actions, each runnable only when its requirements are satisfied. The system repeatedly scores every eligible action by utility and picks the strongest candidate, which yields smooth blending between behaviors: none of the brittle gatekeeping typical of finite state machines, none of the explicit planning overhead of GOAP. Once you give that NPC more than about ten actions, though, and tie each utility curve to dozens of parameters, forecasting what it will do in a given situation becomes almost impossible.

Debugging gets ugly fast—"why did it break into a dance instead of attacking?"—because you must chase every utility term and how they combine. Tuning weights per enemy type or scenario also fights the fact that the architecture keeps chasing locally best moves. That is why production setups often pair Utility AI with an FSM for coarse phases, or restrict scoring to explicit contexts so choices stay interpretable.

...exotic ones: HTN, ML, Neural Nets, RL

HTN (Hierarchical Task Network) extends the GOAP idea with hierarchical task decomposition: complex goals are broken into subtasks through a system of methods and primitive actions. It produces structured plans and supports long-term strategic planning for NPCs defined in that way.

Reinforcement learning (RL) and neural networks promise even more dramatic results: agents that learn strong policies through interaction with the environment, adapt to the player's style, and exhibit emergent behavior.

The results speak for themselves: AlphaStar in StarCraft II, OpenAI Five in Dota 2, agents that outperform humans in complex strategy games.

Those successes create an illusion that the technology is ready for broad use, yet training an agent for even a relatively simple game can take millions of rollouts—weeks or months of continuous computation on powerful GPU clusters. A single training run can cost hundreds of thousands of dollars. Moreover, any gameplay change or new mechanic often means restarting training from scratch.

On top of that, trained models can be hard to reason about. Debugging this kind of "black box" is difficult even for the ML engineers who built it. That is why large studios still tend to reserve ML for targeted uses—procedural generation, player analytics, and similar—while relying on classical methods for core gameplay AI, where predictable behavior and controlled costs matter most.

...pathfinding

The A* (A-star) algorithm and its variants are the workhorses of game AI: they search a discrete navigation graph efficiently by combining the cost-so-far from the start with a heuristic estimate of the remaining cost to the goal. Practical tweaks turn that elegant textbook algorithm into something that can absorb hundreds of path requests per frame.

The harder problems are usually building and updating the graph, and turning graph paths into motion in the real level. A* outputs a polyline of nodes, but the character still has to move along it with a body, inertia, clearance, and dynamic clutter in mind. Familiar failure modes include corner snagging on coarse geometry, jams in tight choke points, trouble routing around movers (other NPCs, the player, physics props), and fragile vertical routing (ladders, ledges, jumps). Even so, A* (plus navmesh or grid tooling around it) remains the backbone of most shipped navigation, while every new map still means tuning geometry and chasing edge cases.

... navmesh

Finally, the bedrock of in-game navigation: a navigation mesh (navmesh) turns messy 3D level geometry into a discrete walkable surface made of polygons and the links between them. Each polygon is (usually) a walkable region; shared edges or portals are where the agent can move from one patch to the next.

A good navmesh trades fidelity against cost. Too much detail spawns unnecessary complexity and slows search; too little detail skews paths and causes characters to hug corners or snag. Today's pipelines lean on automatic bakes. Recast & Detour—the open-source stack behind many Unity and Unreal workflows—voxelizes or samples the level and outputs a mesh using agent parameters (radius, height, max step, max slope, and so on). Commercial tools and in-house bakes at big studios add more specialized rules and are tuned to specific engines and production needs.

No generator, however sophisticated, truly understands a level. It does not know a nook is meant for stealth, that a footbridge is scripted to break, or that a ladder needs a bespoke climb. Common bake failures include links through paper-thin walls or open windows, bogus connections between platforms at different heights, doors/elevators/destructibles treated as static, and broken islands in dense spaces.

So modern workflow is automation plus hand pass: designers place jump links, cover hints, corner fixes, and mark areas with special costs, speed scales, or unit-class rules. Without that manual nav polish, the fanciest decision-making stack is like a wheelbarrow with a wheel missing—it can decide what to do, but it still cannot reliably carry it out in the real geometry.

...AI isn't about "smart enemies"

Game AI is mostly about selling the illusion of intelligence. Players need reactions, pressure, and the occasional surprise. Behind the curtain it is still if statements, switches, and a pile of navmesh—exactly the kind of machinery they should not have to think about. "Good" AI is not the same as genuinely smart AI: the job is to entertain and stave off boredom, not to pass a Turing test. A slow-witted opponent is fine if it behaves the way the player expects. A predictable opponent is fine, too: readable patterns make mastery feel earned. A hand-authored script is fine if it is reliable, fun to play against, and does not break the world.

In short, the goal is not to be smart; the goal is to seem smart. If the player believes they are facing something clever, you have done the important part of the work.

Scripts and configs

Embedded gameplay logic often lives in scripting layers: Lua, Python, JavaScript, AngelScript, and similar, especially when the core engine is built in C++. Those languages tend to fail more gracefully at runtime and can save a lot of iteration time. Even if you are writing an engine from scratch, it pays to plan for scripting early and to keep the host language's strengths and limits in mind: that reduces glue cost and keeps integration straightforward.

Building an engine still means writing plenty of code; there is no real shortcut. Which language should you pick? Frankly, what you already know well matters more than the label on the tin. A seasoned developer will squeeze much more out of performance-sensitive paths in a familiar language and will sidestep the usual traps more reliably. Low-level options such as C++ give you clear control over resources, but they expect solid architecture judgment and a firm grasp of how systems fail and scale.

...it's not about performance or FPS

Script layers and data-driven configs exist mainly so designers can iterate quickly and so less engineering-heavy teammates can contribute safely. High-level languages—Lua, Python, a bespoke DSL, or similar—give you a flexible sandbox for gameplay prototyping: tune balance, try new mechanics, and adjust AI behavior without kicking off a full native rebuild or pulling an engineer into every tweak.

With a low-level-only workflow, even small changes often mean compile, link, and deploy—minutes to hours, depending on the codebase. Interpreted scripts plus JSON/XML-style configuration draw a clean boundary between the stable C++ core and the volatile content layer. You pay a modest runtime tax (parse time, interpretation) but you buy shorter iteration loops, easier A/B experiments, and content patches that do not require shipping new binaries.

...it's about convenience and development speed

Scripting enables a fundamentally different development rhythm: the write–test–fix loop collapses to seconds because languages are interpreted and many setups support hot reload. You can nudge an enemy's detection logic or aggression tuning and see the outcome immediately in-game. Modern engines add live inspectors, debug consoles, and visual debugging hooks - exactly what you want when design asks for constant pivots. Standing up several AI behavior variants in one evening becomes realistic, so teams can experiment without treating every idea like a production milestone. Compared with the C++ pipeline, where each tweak might cost thirty seconds to minutes of rebuild time, a script-forward workflow is simply easier to stay "in the zone" with.

...surprisingly, it's also about safety

Sandboxed scripting is mostly about isolation: each script runs inside a controlled environment with a deliberately narrow API. In Lua, for instance, you can spin up separate VMs (lua_State) with their own global tables and expose only the bindings you intend—blocking raw filesystem access, sockets, process spawning, and similar primitives unless you explicitly whitelist them. Typical gameplay-facing surfaces might look like SpawnActor(), GetPlayerHealth(), or PlaySound().

You can also cap risk operationally: maximum CPU time per script tick, memory budgets, instruction budgets, call counts, recursion depth (whatever your VM exposes) and hard-stop the script when a limit trips. When script code misbehaves, the interpreter can usually trap the error, log context, and let the native core keep running. Native plugins and dynamically loaded modules are different: they generally execute in-process with the engine, so a stray pointer or buffer overrun can still take the whole process down.

...it's about overall project reconfigurability

Hard-coded literals in C++ become architectural friction: every tweak to an AI tunable forces a full native iteration: preprocess, compile, link, ship bits and before anyone can feel the change in-game. That pain shows up fastest when you are chasing numbers such as damage modifiers, nav penalties, aggression thresholds, or weapon timings. The straightforward fix is to push anything gameplay-facing into external data (JSON/XML/INI), spreadsheets, custom DAG formats, or database rows, so designers can rebalance without touching source. Many engines layer reflection-style property systems on top so values hydrate from disk and can be edited live in inspectors.

Hot reload for scripts usually boils down to watching files and re-importing modules: the tooling notices that a script changed, reloads that unit inside the running interpreter, and keeps the native host process alive. That workflow matters when you are iterating on AI rules, event handlers, or broader mechanics and want feedback without a reboot cycle.

...it'so a door for the community

User-generated content needs a low floor for contributors: easy tooling and modest prerequisites. Shipping a mod-facing C++ surface usually means an SDK with headers, build docs, ABI promises, and matrix-testing across compiler versions and platforms: Visual Studio generations, GCC, Clang, and whatever else your players use. Scripting sidesteps much of that: the interpreter already ships inside the game, so modders mainly need an editor, your dialect docs, and enough syntax to stay out of trouble.

A modular script API also gives you a narrow contract: gameplay-facing calls stay stable while native internals churn. Native plugins are different—engine upgrades often force rebuilds, toolchain bumps, and subtle breakage even when nothing "meaningful" changed on paper. Script packs tend to keep working across releases as long as the exposed bindings and semantics stay compatible.

...you can't please everyone

Lua has become the de facto gold standard for embedded gameplay scripting: small runtime, fast enough for tight loops, straightforward C/C++ binding, and oceans of examples and reference material. Most titles drive it from a single gameplay thread; when teams need parallelism, they typically spin up separate Lua states (or isolate work carefully), rather than treating one VM as freely multithreaded.

Python's ecosystem is deep and the syntax is approachable, but shipping it inside an engine is often painful: interpreter startup, packaging, the GIL, and embedding details can consume engineering time you would rather spend on gameplay. That friction pushes many projects toward Lua for in-engine scripting.

JavaScript, through embeddable engines (V8, QuickJS, etc.), can deliver strong throughput and reasonable memory use—modern JIT/AOT JS stacks are mature, and for some teams they are a credible alternative to the usual Lua route.

Smaller embeddables—AngelScript, Wren, Squirrel, ChaiScript, and friends—fill niches. They trade different ergonomics and feature sets, and could have been stronger contenders if Lua had not become the default reference point; today they are usually judged against that baseline.

Networking

It is no secret that everyone dreams about it: persistent worlds, co-op, PvP, MMO-scale ambitions, or even simple player chat. Then you crack open Wireshark and your dreams narrow to one thing—getting any of it to actually run.

Here is the good news first: your game may not need networking at all. If you are building something offline—a puzzle game, a platformer, or "SimTower but with toads"—you can happily ignore the whole topic. If "multiplayer" suddenly sounds tempting, though, tighten your seatbelt. You are stepping onto a road where everything matters, and there is no universal architecture that fits every title.

Modern languages such as C#, Rust, or Go ship tolerable ergonomics for sockets—async IO, nice coroutines, that sort of thing. In C++ (you have my sympathies) you will probably reach for a battle-tested third-party stack such as RakNet, ENet, or similar. None of them feel "brand new," but they have shipped in countless titles.

Sockets are only the handshake at the door. Establishing a connection is roughly one percent of the job; the interesting problems start immediately afterward. What exactly is a "networking engine," anyway? Good question—I asked myself the same thing while hacking together my first co-op prototype. I never got a crisp definition, but I collected a long list of features you suddenly care about, which I will walk through next.

...state synchronization

This is the bedrock of multiplayer, and also one of the hardest parts of network programming. Every participant runs their own local simulation of the world, yet those simulations must stay compatible enough that play feels coherent. Perfect lockstep is not achievable in principle: latency means that by the time news of one player's action reaches everyone else, the situation may already have moved on.

So, teams pick strategies that match the genre. Turn-based games can pause until acknowledgements arrive. Real-time titles usually trade purity for responsiveness—either constrain pacing to the worst connection, or predict locally and reconcile mistakes afterward. Another common pattern is an authoritative server: simple conceptually, tough on high-latency clients who constantly receive corrections.

Fast-moving interactions are where it gets ugly—mutual kills, two players grabbing the same pickup, racing inputs on a contested objective. Some arbiter (often time-stamped server adjudication plus latency-aware rewinds) has to decide what "happened first," even though each player experienced different delays. Get that wrong and players see constant rewind-snaps—"rubberbanding"—as the simulation reconciles against what actually occurred.

...input prediction and rollback netcode

Rollback netcode keeps fast games playable even when latency is high. The idea is straightforward: do not stall the simulation waiting for remote input—advance locally using predictions. When real inputs finally arrive, compare them with what you assumed; if they disagree, rewind to a saved checkpoint and replay forward with the corrected inputs.

Shippable rollback stacks almost always need fast snapshotting or equivalent bookkeeping: enough history to restore an earlier timestep and resimulate deterministically. Practically, that means storing periodic world snapshots or compact state deltas—positions, velocities, animation phases, RNG seeds, anything that affects simulation outcomes—plus the input stream needed to replay.

When a mismatch fires, you load the snapshot at the divergence point and fast-forward to "now," applying the true inputs along the way. Done well, players barely perceive the correction—the game keeps feeling crisp even around 100–150 ms RTT, where naive lockstep feels awful.

The catch is engineering cost: the gameplay simulation must be deterministic and replay-safe, which often forces broad refactors across gameplay code, physics hooks, and fixed-point or controlled-float policies. Saving "the entire world every frame" is the textbook mental model; production engines usually optimize that snapshot strategy, but the obligation remains the same —you must be able to reconstruct the past quickly enough to hide latency.

...interpolation, extrapolation, smoothing

Networked games constantly deal with messy delivery: packets show up at uneven intervals, drop entirely, or land out of order. If you simply apply each update as it arrives, motion looks choppy and often unplayable. Interpolation smooths that out by blending between known samples, if you know a player was at point A at time T1 and at point B at time T2, you can render a continuous motion between those keys instead of snapping.

Extrapolation pushes further: you guess where something will be next from its current velocity and heading so you can keep moving it while you wait for fresh data. The trade-off is accuracy— the longer you predict ahead, the more likely the object suddenly stops or turns, and your guess diverges from reality.

...secure communication protocol

Network protocol security begins with never trusting the wire blindly. Every inbound message should be validated: correct framing, sane ranges, and consistency with what that peer is allowed to do right now. If you apply client-supplied state without checks, you invite classic exploits: arbitrary teleports, inventory stuffing, stat inflation, and worse.

Authentication and authorization harden the perimeter: only legitimate clients should join a session, and each peer should only act within its role. Sessions normally start with identity proof—tokens, signatures, or platform-issued tickets—and critical operations should re-check permissions and freshness. Rotate credentials on a sensible schedule, enforce validation on high-risk actions, and treat session keys as a second line of defense so a stolen long-lived password does not instantly mean game over.

...encryption (you don't get paranoid for nothing)

Encryption in games is not paranoia, it is basic hygiene. Even casual titles move data that should stay private: progression, virtual currency, handles tied to accounts. Modern capture tools are so approachable that unencrypted traffic is trivially observable. TLS is the usual baseline for protecting bytes on the wire, but cryptography is not free: handshakes cost round trips, and ciphered payloads add CPU to margins that can sting in latency-sensitive modes where tens of milliseconds matter. That is why many realtime stacks blend approaches, such as lighter session crypto for steady-state updates, selective encryption for the highest-risk fields, or tuned stacks built for games and while still refusing to ship gameplay plaintext that trivially enables spoofing and griefing.

...object replication

In a multiplayer game, the same logical object often exists in several places at once: on the server, on each client, and sometimes in more than one representation on the same machine (for example, authoritative versus predicted). The server copy typically owns the facts that matter for outcomes (health, transforms, inventory counts), while what you render locally may be interpolated, extrapolated, or rolled back.

A replication layer must choose what to sync, how often, and to whom. Private facts (full inventory loadouts, quest flags, hidden traps) should narrowcast to the owning player; public signals (rough pose, equipped silhouette, team tint) can broadcast to everyone who needs them for rendering or fairness. Delta compression and other bandwidth tricks shrink payloads, but each trick adds edge cases you must reason through when state diverges.

...logging and debugging

Logging in networked games is not merely an ops checkbox. For contentious bugs you often want an audit trail for player inputs, meaningful state transitions, and sometimes even packet-level breadcrumbs when you can afford it.

The catch is volume: a busy title can spill gigabytes per hour if you log naively. Production setups therefore rate-limit, sample, struct-tag, and compress, and they aggressively drop chattier channels in hot paths.

Structured logs (timestamps, build ids, match ids, player ids, entity ids) are what let you rebuild a story after the fact. When a report says "my unit turned into a different type," you need a thread you can follow: spawn time, command stream, authority changes, template swaps, replication apply order. Without that kind of chain, the bug becomes guesswork.

... dealing with cheaters

Fighting cheaters is a slow arms race, and the house does not win every round. Every mitigation invites a countermeasure; every anti-cheat update trains tooling to adapt faster. The structural issue is simple: part of your game executes on hardware the attacker owns. Anything you ship to the client can be inspected, patched, replayed, or spoofed at some level of effort.

Server authority is still your backbone: validate outcomes and sanity-check inputs so blatant lies die server-side. Pure perfection would mean simulating everything centrally, which quickly collides with responsiveness and cost, so teams settle on layered checks on the moments that matter.

Client-side anti-cheat scans memory and modules for known signatures and anomalies. It can help, but it walks straight into trust and privacy debates: kernel drivers and elevated monitors feel invasive, players hesitate to install them, and false positives annoy legitimate setups from capture tools to security suites.

UI

You can ship a game with no physics, no AI, even no sound. Shipping without UI is almost impossible. These days a completely UI-less title reads as intentional avant-garde indiesperimentation. Besides, you still need somewhere to put New Game and Quit.

On paper it sounds trivial: draw a few buttons, drop in labels, maybe a slider. Then reality arrives. Interactive widgets accumulate states. A button is not one bitmap; it is idle, hovered, pressed, focused, disabled, and sometimes half a dozen custom variants. Same story for fields, toggles, lists.

Hierarchy piles on complexity. Modern screens are trees: a button lives inside a row inside a panel inside a sheet that might not exist until a tab opens. Each layer needs layout, clipping, focus routing, and visibility rules that do not fight each other.

Coordinate spaces make UI math fiddly. Meshes live in one world space; UI fragments flip between pixel screenspace, scaled logical units, and parent-relative boxes. Hit testing, anchoring, DPI scaling, and safe areas all sit on top of that stack.

Input parity is another whole axis. Desktop expects mouse precision and keyboard traversal; mobile expects fat fingers and gestures; consoles expect focus rings and analog navigation. One layout rarely fits all without deliberate affordances.

Polish is where hobby UI dies and production UI begins: transitions, micro-motion, feedback on press, disabled styling that still reads clearly. None of that is mere ornament; it is what separates "dead controls" from something that feels alive.

And then you notice the trap: you set out to ship a game, but you are halfway to authoring a mini framework that may never leave this codebase. Even when you embed a mature stack (Scaleform is better than its reputation, for what it is worth), you still owe integration work: input translation, event bubbling, font atlases, shader passes, batching, localization hooks.

So yes, UI is structured, layered, platform-sensitive work that teams routinely underestimate. It is still worth doing properly at least once, even in a small scope. Just do not expect weekend one to reproduce Unity UI, Unreal Slate, or the entire HTML ecosystem.

Tools

Not every engine or game needs a heavyweight toolchain around it, and that should not surprise anyone. Sometimes a handful of Python glue scripts is enough. Many commercial stacks ship editors that feel like an IDE crossed with a DCC app: place entities, tweak materials and shaders, tune physics, scrub animations, poke UI, and scrub changes live.

Building an editor that polished is almost as expensive as building the runtime itself. For a small custom engine, chasing Unity-parity chrome is usually a bad ROI: months disappear into docking layouts and undo stacks you never needed.

Still, do not ignore small tools. A few evenings of scripting for bake helpers, batch exporters, or sanity validators routinely buys back weeks of manual slog later.

...level converters

Custom binary schemas exist because you often want load paths that map cleanly onto engine structs and arrays with minimal translation cost.

Text interchange formats such as JSON or XML pay for human readability at runtime: lexing, parsing, string-to-number conversion, heap churn. A well-designed packed blob can mmap or fread straight into layouts you already use in simulation, which matters when a level streams thousands of transforms, material handles, and tagging metadata.

Binary pipelines also give you room for embedded compression, baked LOD chains, precooked nav data, hash tables, whatever preprocessing saves milliseconds on the critical path.

Conversion tooling ties into normal asset workflows: watch folders, rebuild packs when sources change, split authoring formats from shipping blobs so artists keep familiar exporters while engineers evolve on-disk layouts or platform-specific variants without forcing daily disruption.

...asset validation

Asset validation is one of the few things that cheaply pays for build integrity: it blocks bad data before it poisons a milestone. Validators walk reference graphs, because every serious asset points at other assets through GUIDs, source paths, or custom handles, and a missing link is a late-night crash you do not want in QA.

They also enforce content rules: materials must resolve textures, mesh chunks must bind valid skeletons, animation clips must line up with rig definitions, shader permutations must exist for the platforms you actually ship.

Hook those checks into CI and the content bake so failures surface with filenames, not mystery repros. On big teams, that is how you keep an artist's innocent rename from silently deleting someone else's dependency three departments away.

Time invested in tooling should pay rent: if a workflow still means hand-editing two hundred lines of JSON, a small exporter or inspector script will usually earn its keep faster than another meeting about process. You still should not build a glittering editor "because engines have editors," but targeted automation is rarely wasted effort.

Architecture

Eventually the parts exist: rendering, audio, data, physics, UI, maybe AI and scripts. The missing question is how you wire it all into something that runs as one product. A few established patterns keep showing up in production codebases.

...no architecture is also architecture

After fighting overbuilt frameworks, many small teams fall back to a deliberately dumb architecture: a handful of independent libraries, each owning one slice of the problem. You wrap rendering behind a gfx module, audio behind audio, streaming behind assets, polling behind input. Modules stay loosely coupled on purpose; nothing magically knows about anything else unless you wire the calls.

That was the default posture of late-nineties and early-aughts codebases. It is quick to stand up, easy to reason about in small scopes, and leaves execution order entirely visible.

Discipline becomes the hidden dependency: without scene graphs or forced pipelines, nothing stops you from forgetting a step.

Scale hurts first in your head: the call graph sprawls, initialization order turns fragile, and regressions arrive as subtle sequencing bugs. UI stops refreshing after a content reload, music fails to cue on level transition, physics wakes before assets finish streaming. Each fix is manual glue, because the missing piece was never "library quality," it was composition.

Ironically, the wiring you tried to postpone is the architecture. Evading structure does not delete it; it just relocates the burden into ad hoc calls sprinkled everywhere.

...godobject is also architecture

Large game engines like Unity, Unreal, Godot, CryEngine, Dagor, and others often adopt an approach based on a single base class. Typically named Object, Entity, GameObject, Actor, or similar, this class becomes the ancestor of all game entities. This base class usually contains virtual methods for core game functions:

struct GameObject {
  virtual void update(float dt);
  virtual void render();
  virtual void onEvent(const Event&);
};

Everything you author, from HUD widgets to hostile NPCs, subclasses one mega-type. Each instance magically inherits tick callbacks, draw hooks, and event plumbing. Convenient? Extremely. You get a uniform surface area "for free," plus a natural place to hang a central registry.

The downside is inheritance sprawl: one mammoth base class fights composition, mixing orthogonal concerns into the same vtable. Want multiple reusable behaviors? You bolt more flags and overrides onto GameObject. Within a few milestones that base type balloons into hundreds of lines of virtual hooks.

Bolting "components" onto the same hierarchy often compounds the mess instead of curing it. Eventually you regret the shape of the tree, yet countless shipped titles prove you can still finish under this pattern if scope stays modest.

...ECS is good! But...

This architectural model has exploded in popularity among indie developers and enthusiasts in recent years. The core idea is a radical separation of data and logic, built around three key concepts. An entity is just an identifier, with no logic or data of its own. A component is a container for a specific type of data, such as position, health, or sound parameters. A system is a functional block that processes components according to specific rules. None of them works alone, but together they replace traditional object hierarchies with batch-oriented data processing.

For instance, a physics system can walk all entities that have both Transform and Velocity and update every moving object's coordinates in one structured pass. Benefits include strong performance from cache-friendly layouts, clearer separation of responsibilities between subsystems, and good scalability.

Drawbacks include jumping straight into a fairly complex architecture that often needs a lot of boilerplate and patterns. Without specialized editors, ECS-heavy codebases can be hard to read, and without visual debugging tools, diagnosing issues gets painful. For smaller projects, it can feel like using a sledgehammer to crack a nut.

Game engine

Maybe you should leave everything exactly as it is? Yes and no. The engine, and the scaffolding around it, is a means to an end. If you are hacking on a weekend hobby project, do not chase the perfect framework, or you may ship nothing but scaffolding while the actual game keeps slipping. Still, architecture matters the way a skeleton matters: nobody admires your ribs in screenshots, but if the bones are crooked, everything built on top aches, bends, and snaps under light stress. When the structure becomes genuinely painful, do not be precious about it. Throw it out and rebuild. Everyone tosses bad foundations sometimes (that is the spirit behind the "three systems" rule). Classics such as Jason Gregory's Game Engine Architecture remain relevant because nobody has handed us a strictly better substitute.

To learn how games actually tick, you do not need an Unreal-scale codebase on day one. If you want to avoid becoming yet another résumé line that reads "Unreal C++" yet hides shallow familiarity with how containers or allocators behave, try shipping your first or second project with minimal middleware. Make something deliberately crude: a window, a handful of sprites, a tiny resource loader that stuffs textures into a .zip. Call it a toy engine if you like: simple, buggy, full of reinvented wheels, but yours, and built while knowing what each lever does. Skip Unity, skip Godot, skip the polished shortcuts that quietly vault you past ninety percent of what is happening under the hood.

You will fight architecture problems, patterns, and asset budgets head-on. It costs calendar time, but you earn more than a demo reel clip: you earn intuition about internals that is hard to fake in interviews. That is where serious growth starts, without borrowing momentum from black boxes. Someone who only knows editor wiring may stay boxed into one toolchain; someone who understands memory layouts, threading contracts, and asset pipelines can adapt across engines.

That said, if Godot, Unreal, or another turnkey stack matches your patience and goals, use them. Ambition and pace matter more than purity contests. Even if you eventually standardize on third-party tech, the scars from rolling your own stack become leverage: you stop treating engines like magic and start reading them as engineered systems.

As always, the choice is yours.

Author: Sergei Kushnirenko

All parts

Game++. Part 1.1: C++, game engines, and architectures