DEV Community: Unicorn Developer

Let’s make a programming language. Variables

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

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

So far, our programs have consisted of a single expression built from smaller language constructs. Now it’s time to evolve the language.

Instead of parsing a single expression, we'll introduce a list of declarations, allowing our language to support variable declarations and laying the groundwork for more complex programs.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Foreword

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

A word about the project

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

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

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

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

Error review

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

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

Unused parameter

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

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

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

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

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

Missing case in a switch statement

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

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

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

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

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

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

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

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

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

Losing a parameter's value

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

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

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

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

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

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

A copy-pasted condition

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

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

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

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

A misunderstanding of operator precedence

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

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

    ....
  }
  ....
}

The PVS-Studio warning:

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

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

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

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

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

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

Potential null dereference

Issue 1

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

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

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

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

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

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

Issue 2

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

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

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

The declaration of the Locator method explains why:

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

  return element;
}

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

Issue 3

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

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

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

Conclusion

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

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

See you in the next articles!

Game++. Part 1.4: Game engine architectures

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

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

CryEngine (Microkernel Architecture)

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

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

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

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

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

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

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

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

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

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

Picture 2.7

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

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

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

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

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

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

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

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

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

Picture N2.8

Dagor (Data-driven Architecture)

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

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

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

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

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

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

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

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


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

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

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

The final configuration ends up with rendinstDistMul = 0.8.

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

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

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

X-Ray Engine (Monolith Architecture)

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

Picture N2.9

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

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

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

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

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

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

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

Picture 2.10

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

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

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

Godot (Modules/Services Architecture)

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

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

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

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

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

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

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

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

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

Author: Sergei Kushnirenko

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

All parts

Game++. Part 1.1: Game engine architectures

Game++. Part 1.2: Game engine architectures

Game++. Part 1.3: Game engine architectures

Code slicing: What lies inside OrcaSlicer

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

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

About the project

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

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

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

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

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

Let's dive in

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

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

Example N1

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

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

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

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

Example N2

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

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

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

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

This pattern repeats two more times in the code:

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

Example N3

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

class RasterBase {
public:

  enum Orientation { roLandscape, roPortrait };

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

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

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

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

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

Example N4

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

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

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

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

The same warning:

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

Example N5

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

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

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

The fixed code:

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

Example N6

PVS-Studio warnings:

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

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

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

  return plate_item;
}

// ....

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

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

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

Example N7

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

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

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

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

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

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

Example N8

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

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

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

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

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

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

Spoiler: no, they aren't

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

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

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

  // .... 
};

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

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

typedef SM_Face_index Face_index;

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

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

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

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

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

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

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

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

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

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

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

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

Example N9

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

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

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

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

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

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

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

Other V609 warnings:

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

Example N10

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

template <typename LineType>
class LinesDistancer {

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

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

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

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

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

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

Example N11

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

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

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

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

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

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

Example N12

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

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

  return "";
}

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

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

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

Example N13

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

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

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

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

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

Example N14

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

class OptionsZCorrector
{
  GCodeProcessorResult& m_result;

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

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

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

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

Looking ahead

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

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

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

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

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

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

Introducing ES2026: what's new in the standard?

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

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

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

Runtime Showdown: Node.js against the World

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

Full details are on the Node.js Official Blog.

TypeScript 7.0: Beta announcement and migration to Go

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

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

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

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

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

What to read?

TypeScript Tips Everyone Should Know

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

Error that we had to ignore

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

JavaScript in 2026: A Comprehensive Guide to the Ecosystem Revolution

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

TypeScript at scale in 2026: What senior engineers should know

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

What to listen?

Podcast: TypeScript.fm

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

Podcast: Syntax.

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

Wrap-up

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

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

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

Get the 30-day trial promo code here!

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

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

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

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

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

Story #1

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

Story #2

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

Story #3

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

What does expertise mean for PVS-Studio?

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

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

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

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

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

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

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

A few words about the series of live talks

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

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

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

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

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

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

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

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

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

Revealing secrets

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

Story #1

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

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

Story #2

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

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

Story #3

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

Some parting words

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PVS-Studio 7.43: Unreal Engine support in Team license, extended MISRA C++ 2023, Zephyr SDK support, and more

Unicorn Developer — Fri, 19 Jun 2026 12:17:35 +0000

PVS-Studio 7.43 has been released. This version features expanded support for MISRA C++ 2023, Unreal Engine integration in the Team license, Zephyr SDK support and much more.

Unreal Engine support in the Team license

Good news for Unreal Engine developers: analysis of Unreal Engine projects is no longer limited to the Enterprise license. Starting with PVS-Studio 7.43, this functionality is also available in the Team license.

Learn more about the analysis of Unreal Engine projects

MISRA C++ 2023

We continue to expand our support for MISRA C++ 2023.

In this update, we've adapted 12 existing diagnostic rules from the MISRA group to comply with the MISRA C++ 2023 standard.

Lean more about the support of the MISRA standard

Zephyr SDK support

PVS-Studio 7.43 can now analyze projects that use compilers from the Zephyr SDK. You can inspect such projects via compile_commands.json or build monitoring.

Learn more about the integration

Analyzer improvements

We've enhanced the interprocedural loop analysis in the C and C++ analyzer. Now the analyzer can evaluate canonical loops and factor in possible value ranges of variables.

The C# analyzer now supports .NET SDK version 10.0.300 on Linux and macOS.

Learn more about the analyzer usage on these platforms.

Reminder: Our Early Access Program for JavaScript and Go analyzers and the Atlas code quality management platform is still open. You can now also evaluate PVS-Studio for TypeScript.

If you'd like to participate, simply, please fill out the form on our website.

New diagnostic rules

Java

V6135. The return value of the 'finally' block overrides return values of 'try' and 'catch' blocks.

Articles

Here is our traditional roundup of blog articles! Over the past two months, we've posted articles exploring vibe-coding, covering alignment in C++, error handling in Go, and the new features of Java 26, celebrating the evolution of our mascot Cody, and much more. Below is the full list.

C and C++

C

Java

What's new in Java 26

JavaScript

Error that we had to ignore

Go

Webinars

Let's make a programming language. Grammars

In our first session, we explored the core building blocks: the lexer, parser, semantic analyzer, and evaluator—how they work and how they fit together. Now it's time to dive into grammars. What is a language, really? How can you describe it in a way that a program understands what a sequence of symbols means and what result it should produce? We'll break it down in a clear and practical way—and, of course, get hands-on with grammars.

Let's make a programming language. Lexer

The lexer is the part of the parsing pipeline that operates on terminal symbols. It takes a raw input stream and turns it into a sequence of tokens—classifying lexemes into meaningful units. This process, as you know, is called tokenization. We won't stop at theory. During the webinar, we'll walk through how a lexer is actually implemented in code. This session is aimed at developers who want to go beyond using languages and start understanding how they work under the hood.

Want to see more webinars, we invite you to check out upcoming events on the webinar page.

Conclusion

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

Do you want to check your project with PVS-Studio? Start with a trial license!

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

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

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.

DEV Community: Unicorn Developer

Let’s make a programming language. Variables

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

Foreword

A word about the project

Error review

Unused parameter

Missing case in a switch statement

Losing a parameter's value

A copy-pasted condition

A misunderstanding of operator precedence

Potential null dereference

Conclusion

Game++. Part 1.4: Game engine architectures

CryEngine (Microkernel Architecture)

Dagor (Data-driven Architecture)

X-Ray Engine (Monolith Architecture)

Godot (Modules/Services Architecture)

All parts

Code slicing: What lies inside OrcaSlicer

About the project

Let's dive in

Looking ahead

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

Introducing ES2026: what's new in the standard?

Runtime Showdown: Node.js against the World

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

What to read?

What to listen?

Wrap-up

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

Story #1

Story #2

Story #3

What does expertise mean for PVS-Studio?

A few words about the series of live talks

Revealing secrets

Some parting words

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

PVS-Studio 7.43: Unreal Engine support in Team license, extended MISRA C++ 2023, Zephyr SDK support, and more

Unreal Engine support in the Team license

MISRA C++ 2023

Zephyr SDK support

Analyzer improvements

New diagnostic rules

Java

Articles

C and C++

C

Java

JavaScript

Go

Security

GameDev

Other

Webinars

Let's make a programming language. Grammars

Let's make a programming language. Lexer

Conclusion

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

About the speaker

Meet the parser

Parser implementation

Want more?

Game++. Part 1.3: Game engine architectures

Unity (Unitary Architecture)

Big Ball of Mud

Unreal Engine (Layered Architecture)

All parts

Changes to PVS-Studio's student licensing policy

Error that we had to ignore

Background

More noise than signal

Hide the pain Harold

Unsound static analysis

Why not make a more precise exception?

Afterword