DEV Community: Unicorn Developer

I found some bugs in Create mod and checked them in Minecraft

Unicorn Developer — Tue, 29 Sep 2026 13:29:42 +0000

This article covers bugs in Create, one of the most popular Minecraft mods. Let's see how they impact the game and then submit pull requests with the necessary fixes.

Introduction

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

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

Let's check the project

Some important info

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

Ctrl + V doesn't work

The SchematicEditScreen.java(130) file

Let's take a look at the menu for pasting a schematic.

What's a schematic?
A schematic is a part of the game world saved as a separate file. This lets you move your house from one world to another, for example.

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

The PVS-Studio warning:

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

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

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

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

After opening the menu, I saw the expected behavior:

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

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

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

Unnecessary maximum

The ScheduleScreen.java(557) file

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

The PVS-Studio warning:

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

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

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

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

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

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

Ignore error handling

The MechanicalCrafterBlockEntity.java(535) file

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

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

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

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

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

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

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

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

  phase = Phase.ASSEMBLING;
  countDown = 1;
}

The PVS-Studio warning:

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

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

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

  if (!isCrafter(blockState))
    return crafters;

  ....
  return crafters;
}

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

Before the fix:

After the fix with isEmpty:

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

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

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

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

The logging crash

The TrainRelocationPacket.java(52) file

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

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

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

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

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

  ....
}

The PVS-Studio warning:

V6008 Potential null dereference of 'train'. TrainRelocationPacket.java 52

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

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

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

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

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

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

The two-state theory

The MechanicalMixerBlockEntity.java(238) file

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

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

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

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

  if (availableItems == null)
    return matchingRecipes;

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

  return matchingRecipes;
}

The PVS-Studio warning:

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

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

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

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

Method contracts must be followed

The Contraption.java(230) file

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

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

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

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

The PVS-Studio warning:

V6008 Potential null dereference of 'contraption'. Contraption.java 230

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

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

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

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

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

We can easily add the check:

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

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

Interruption

The ServerLagger.java(14) file

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

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

The PVS-Studio warning:

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

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

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

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

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

Conclusion

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

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

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

Unicorn Developer — Wed, 23 Sep 2026 12:35:34 +0000

We continue the development of our toy programming language. In this episode, our speaker Yuri demonstrates how to implement functions and explains how functions, scopes, and symbol lookup are built in code using C++.

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.

Introducing scopes

Functions introduce multiple scopes and different levels of name visibility. Unlike variables, which previously existed only in the global scope, functions create their own scope. Names declared inside a function are not visible outside it, while names from parent scopes remain accessible. Compound statements can also create nested scopes.

Managing the symbol table

To resolve names, the semantic analyzer uses a symbol table that associates names with their declarators and the scopes where they appear. Two lookup methods are used. An unscoped lookup searches the current scope and then moves upward through parent scopes until it finds the name. A scoped lookup checks only a specified scope. The latter also prevents duplicate names from being declared within the same scope.

Parsing functions

A function consists of the fn keyword, a name, parameters, an optional return type, and a compound statement containing its body. Parameters have a type and a unique name. Functions are parsed in two stages: the declaration is parsed and registered in the symbol table before the body is processed. This allows the function to reference itself recursively.

Handling return types

The semantic analyzer determines a function's return type from its return statements when no type is specified. It also checks that return expressions are compatible with the function's return type and adds implicit casts when necessary. An empty function with no return statements gets the void type. Incompatible return types make the function invalid.

The talk concludes with functions implemented and introduces the evaluator as the next step.

Want more?

If you want to watch other talks, follow this link.

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

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

See ya!

Live talk on how to create your own Go analyzer

Unicorn Developer — Fri, 18 Sep 2026 12:48:45 +0000

Static analyzers are powerful tools, and any Go developer who has worked with go vet knows how useful they can be. What happens when the tools you have at your disposal don't catch the most important issues in your projects, though? You could look for another solution... or you could build your own!

In our upcoming live talk, we'll explore how Go's built-in tools and code-parsing capabilities can help you take the first steps toward creating a static analyzer tailored to your needs.

From Go's built-in tools to your own analyzer

A PVS-Studio Developer Advocate will walk you through the foundations needed to understand before building a Go analyzer. We'll start with Go's built-in tools and code-parsing capabilities, then move on to the basics of static analysis. From there, we'll look at what a semantic model is and how it fits into the analysis process. Another important part of the talk will be building a syntax tree.

The goal of this talk is to bring all the pieces together and show how they can be used to create your own static analyzer. Instead of relying solely on existing tools, you can tailor an analyzer to catch the issues that matter most in your projects.

Join us live

Join us on September 30, 2026, at 1:00 PM UTC+1 for "Go vet can't go: How to create your own Go analyzer?"

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

Unicorn Developer — Thu, 17 Sep 2026 11:41:35 +0000

PVS-Studio 8.0 is here! We added support for Go project analysis and much more. This article discusses some of the new diagnostic rules for Go that we developed for the latest version of our analyzer.

Introduction

PVS-Studio 8.0 officially introduced support for analyzing Go projects, as well as the option to work directly from GoLand and Visual Studio Code when using Go.

The Visual Studio Code plugin also received a major overhaul. It now supports Go project analysis and all the new analyzers introduced in PVS-Studio 8.0. You can learn about other new features in the press release.

The new release also added 40 new diagnostic rules for Go to the analyzer. In this article, we'll take a look at some of the most interesting ones, explore different use cases, and compare them with traditional tools. Enjoy the read!

Classic errors

We'll start with something that isn't specific to the Go language. Instead, let's focus on more universal and familiar territory: the mistakes that anyone can make when coding or communicating, regardless of the language used.

I should mention that our approach to the "typical developer mistakes" is somewhat different. In addition to studying Go projects, developer forums, and other resources, we used our "secret weapon" to develop diagnostic rules that detect common issues.

That's 18 years of experience searching for issues in code :)

Thanks to this experience in developing analyzers for C, C++, C#, and Java, we've built solid expertise in detecting common mistakes that developers can make regardless of the language they use. This enables us to consider more error cases and scenarios when designing a new analyzer.

Mistakes like typos, copy-paste errors, and other patterns inherent to human behavior may seem simple...

Let's look at a few examples.

Accessing by constant index within a loop

The example:

for i := 0; i < n; i++ {
    sum += arr[0]     // <= It should most likely be arr[i]
}

The PVS-Studio warning: V8008. Suspicious access to a collection element by a constant index inside a loop.

This diagnostic rule is interesting because the issue isn't a syntax error, but rather a logical one—a mistake that developers of any skill level can make.

The index is syntactically valid, so the compiler doesn't report the error, but it remains. Situations like "Oops, I forgot to change i to j" or "I forgot that i even existed" are far more common than you might think. At this point, it becomes a pattern rather than an isolated issue.

We cover this because we know firsthand that developers make such mistakes! Each of our "classic" analyzers has equivalent rules (V3102 is for C#, V767 is for C++, and V6016 is for Java) and includes examples of such mistakes found in popular open-source projects. So, these issues shouldn't be underestimated. You can find examples of errors here:

C# examples (.NET 8, Orleans, PascalABC.NET, etc.);
C++ examples (Godot Engine, RT-Thread, etc.);
Java examples (Apache Solr, Bouncy Castle, Apache Dubbo, etc.).

Recurring condition check

The example:

if A == B {
  if A == B {
    ....
  }
}

The PVS-Studio warning: V8020. Recurring check. This condition was already verified on a previous line.

As you can see, I wasn't lying when I said these mistakes look simple... almost too simple.

And that's the scary part! You get this strong feeling, "I'd never, ever make a mistake like that. I'm not that silly." Then a fly buzzes by, a bug slips through, a colleague walks over, and suddenly there's a couple of checks doing the same thing.

Here's a real-world example from the Incus project, which we covered in one of our articles:

err = p.Save(pidPath)
if err != nil {
    err2 := p.Stop()
    if err != nil {        // <= It looks like it should be err2
        return fmt.Errorf("...: %s: %s", err, err2)
    }
    ...
}

The PVS-Studio warning: V8020 Recurring check. The 'err != nil' condition was already verified on line 407 proxy.go 407

The second condition should check err2 instead of err, as err has already been checked and hasn't changed since.

However, there's more to it because err2 appears in the error handling:

return fmt.Errorf("....: %s: %s", err, err2)

At first, you might not see anything unusual about this context. Although, the answer is obvious: if a problem occurs while handling errors, it becomes more difficult to detect and fix them.

Here's one more point worth mentioning. Go's error-handling philosophy follows a simple principle: "an error is a value." The caller must explicitly handle an ordinary value that a function explicitly returns. Such code is common and boilerplate, so it's easy to make mistakes with it!

We designed one of our new diagnostic rules with this particular aspect of Go in mind:

V8023. It is possible that a wrong variable of the 'error' type is checked for 'nil'.

The example:

func processOrder(orderID string) error {
    order, err := fetchOrder(orderID)
    if err != nil {
        return fmt.Errorf("fetch order: %w", err)
    }

    payment, errPay := chargePayment(order)
    if err != nil {          
        return fmt.Errorf("charge payment: %w", err)
    }

    return savePayment(payment)
}

Now, let's return to the topic of common developer mistakes and discuss copy-pasting. You can notice that err is used instead of errPay in the second case. The result of chargePayment is assigned to a different variable, but developers forgot to change the variable name.

It's easy to spot most of the errors in the context of this article. However, during a code review or while writing code, when we're not looking at a single function but rather going through hundreds or thousands of code lines without a break, it's easy to miss such issues.

We discussed this and other issues related to error handling in Go in the "Error handling in Go: Common pitfalls" article.

The parameter is overwritten before it is used

The example:

func Translate(value *T, numericValue int) {
    numericValue = reader.ReadInt32()   // <= the initial parameter value 
                                        //    isn't used anywhere
    ...
}

The PVS-Studio warning: V8038. A parameter is always rewritten in the function body before being used.

This is a rather unfortunate error because the value passed to the function parameter is never read; it's immediately overwritten inside the function body.

Technically, this isn't a compilation error, so everything should work as expected. However, it usually indicates one of two things: either the input value wasn't used, or the variables got mixed up during refactoring.

Basic tools aren't always enough

Having a nice set of tools right out of the box—and, of course, various open-source solutions—is always great, but they might not be enough for more demanding tasks.

Let's take the very first diagnostic rule of our Go analyzer as an example:

V8001. Identical sub-expressions to the left and to the right of the 'foo' operator.

Look at the example:

func rgb1(r float32, g float32, b float32) {
  if r > 1 || g > 1 || r > 1 {
    ....
  }
}

The error lies in the identical sub-expressions within the binary expression. This issue may arise from carelessly copying code. Such errors are common and nothing out of the ordinary; so, go vet can spot them.

However, things aren't always that simple... Let's take a look at this code:

func rgb(r float32, g float32, b float32) {
  if r > 1 || g > 1 || 1 < r {
    ....
  }
}

The only change is that 1 and r have switched places. Here's the catch, though: go vet doesn't issue any warnings, but the problem remains, since the r > 1 sub-expression is equivalent to 1 < r.

Impossible type assertion

Here's another case involving the V8035 diagnostic rule: an impossible type assertion.

Check out this example:

var v interface {
    Read()
    Read2()
    Read3()
    Read4()
    Read5()
}
_ = v.(io.Reader)

The idea is simple: v is declared as an anonymous interface with the Read() method, whose signature doesn't match Read([]byte) (int, error) from io.Reader/io.ReadCloser (in the example, Read() has no arguments).

So, no specific type can implement both the v anonymous interface and io.Reader/io.ReadCloser simultaneously. So, this implementation guarantees that assertion will throw a panic at runtime. The compiler doesn't catch this because it's technically valid Go code, and everything runs smoothly.

Now wait for it... Go vet can detect it! This is a well-known and well-documented issue, so it should come as no surprise.

By the way, PVS-Studio issues the following message for such code:

The PVS-Studio warning: V8035. Type assertion is always false. Check the 'interface{Read(); Read2(); Read3(); Read4(); Read5()}' and 'io.Reader' interfaces, as they contain methods with incompatible signatures.

Here's another example:

var v interface {
    Read()
}

switch v.(type) {
case io.ReadCloser:
    fmt.Println(1)
default:
    fmt.Println(2)
}

The PVS-Studio warning: V8035. Type assertion is always false. Check the 'interface{Read()}' and 'io.ReadCloser' interfaces, as they contain methods with incompatible signatures.

In fact, it's exactly the same impossible assertion. The only difference is that the assignment is now done using case in the switch statement and via v.(type), rather than via v.(io.ReadCloser).

This is where I'm supposed to say that go vet can't detect it... but no! It can, but that's not the point here. A popular open-source analyzer won't detect the issue here, but it will spot it in the first case. This is a false negative that occurs when a warning isn't issued when it should be.

This presents a dilemma: you can either look for a tool that covers all use cases and spend time trying out different options, or you can take a closer look at PVS-Studio. It's designed for in-depth analysis and comes with guaranteed support for many years to come.

If you have any doubts about our claims, feel free to try our tool and draw your own conclusions.

Well, enough with the synthetic code. Will we show some real code, though?

Some real code

Do you remember the very first Go analyzer diagnostic rule I covered at the beginning of this section? Here's a real example of the warning from the Nuclei project:

func NewEntityParser(dir string) (*EntityParser, error) {

  cfg := &packages.Config{
    Mode: packages.NeedName | packages.NeedFiles | packages.NeedImports |
      packages.NeedTypes | packages.NeedSyntax | packages.NeedTypes |
      packages.NeedModule | packages.NeedTypesInfo,
    Tests: false,
    Dir:   dir,
    ParseFile: func(....) (*ast.File, error) {
      return parser.ParseFile(fset, filename, src, parser.ParseComments)
    },
  }
}

The PVS-Studio warning: V8001 There are identical sub-expressions 'packages.NeedTypes' to the left and to the right of the '|' operator. parser.go 33

If we take a closer look, we can see that the packages.NeedTypes flag is pointlessly repeated here. This error may have occurred due to code autocompletion or a typo. Most likely, there should be the packages.NeedTypesSizes flag here:

const (
  ....
  // NeedTypes adds Types, Fset, and IllTyped.
  NeedTypes

  // NeedSyntax adds Syntax and Fset.
  NeedSyntax

  // NeedTypesInfo adds TypesInfo and Fset.
  NeedTypesInfo

  // NeedTypesSizes adds TypesSizes.
  NeedTypesSizes

  ...
)

It might seem like a simple mistake, but the standard go vet won't catch it. Yet the open-source tool I mentioned in the previous case study does find it. So, I'd like to reiterate the issue: go vet sometimes finds problems that other tools don't, and vice versa.

We discussed this and other errors that the standard go vet can't detect in the "Go vet can't go: How PVS-Studio analyzes Go projects" article.

Go-specific issues

Of course, Go has its own pitfalls. Even seasoned Go developers may not be familiar with all of the language's unique features and tricky parts (not to mention those coming from other languages).

For such cases, our comprehensive documentation provides detailed explanations of why this or that error occurred. We also have examples of common mistakes and how to fix them :)

Well, let's look at a couple of diagnostic rules.

recover() inside an anonymous function that isn't wrapped in defer

In Go, recover resumes execution only if called inside a deferred (defer) function.

However, if an anonymous function with recover is called immediately as (func() { ... }()), by the time a potential panic occurs, that call will have long since completed—recover is physically unable to catch it. So, if a panic occurs, the goroutine can't resume execution.

Here's the example:

func foo() {
    func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered", r)
        }
    }()                        // <= recover started and finished immediately
    q, r := bits.Div64(hi, lo, y) // panic, recover won't help here anymore
}

After defining the anonymous function and calling it, the bits.Div64 function is called. This function can trigger a panic if y equals 0. If that panic reaches the top of the stack, the program will crash.

Of course, the documentation explains how to fix this: the anonymous function call needs to be deferred using the defer keyword:

func foo() {
  defer func() {
    if r := recover(); r != nil {
      fmt.Println("Recovered", r)
    }
  }()
  q, r := bits.Div64(hi, lo, y)
}

For more details, refer to the documentation.

They couldn't have made such a mistake, right?

Here's an error so interesting that we wrote an article about it titled "One mistake no one has ever made. Right?"

Since the article describes it pretty thoroughly and includes examples from real projects, I'll just give a brief overview:

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

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

Here's an interesting thing: when developing this diagnostic rule, we thought it was "far-fetched" and that "no one would make a mistake like that" because any test would catch it. But the results were fascinating! You can check them out in the article.

Confusing XOR (^) with exponentiation

Here's another interesting Go-specific mistake.

Unlike in Lua, VB.NET, and R, in Go, ^ has nothing to do with exponentiation, which can be a trap for developers switching between languages. This mistake is exciting because, if we recall the problem with universal mistakes from the beginning of the article, it results in an unfortunate combination.

Binary expressions meant for exponentiation become incorrect when a developer chooses ^. This operator actually performs a bitwise exclusive OR.

The example is painfully simple:

x := 2 ^ 16

In reality, the value here is 18 instead of the expected 2 to the power of 16 (65,536). As the documentation suggests, we can use the left bitwise shift operator to get the power of 2.

x := 1 << 16

What's next?

If you're familiar with our work, then you've probably heard that PVS-Studio detects code quality issues and serves as a static application security testing (SAST) solution. This means our analyzer can also spot potential vulnerabilities.

Our new Go analyzer currently includes only a basic set of diagnostic rules that cover common code quality issues. This is just the beginning, though!

Consider this an announcement: we've already started working on SAST coverage for our Go analyzer. Stay tuned to our blog for updates :)

To back that up, let me introduce one of the first diagnostic rules in the code security section.

Trojan Source

Take a look at this code fragment:

isAuthorized := false
/* verify before transfer */ if isAuthorized {
    TransferFunds(account, amount)
/* end verify */ }

What do you think it would look like to the compiler (without all the conventions and low-level details)?

If you think it should look like this:

isAuthorized := false
if isAuthorized {
    TransferFunds(account, amount)

Well, you're almost right...

It looks as though the funds transfer is indeed protected by the isAuthorized check.

However, the issue lurks where we can't see it, because the compiler will interpret this as follows:

isAuthorized := false
TransferFunds(account, amount)

It doesn't look that great anymore, does it? The isAuthorized check never runs because the if statement and {...} ended up inside what the reviewer considered to be "commented-out" text, so the TransferFunds call executes unconditionally.

The code contains special characters that may not be displayed. They can change how the code appears in the development environment. Combinations of such characters can cause a human and a compiler to interpret the code differently.

Here's what the code actually looks like:

isAuthorized := false
/*[RLO] } [LRI] if isAuthorized[PDI] [LRI] verify before transfer */  
    TransferFunds(account, amount)
/* end verify [RLO]{ [LRI]*/

Let's briefly go over what these characters do here:

[LRI] if isAuthorized[PDI]: the fragment between LRI and PDI is isolated and evaluated from left to right as a single block (if isAuthorized).
[LRI] verify before transfer */: to the end of the line; this is also an isolated block (verify before transfer */).
[RLO]: reverses from right to left everything that follows it, and each of the obtained isolated blocks is treated as a single, indivisible character.

The final order is as follows:

'verify before transfer */', 'if isAuthorized', {space}, '{', {space}

And, lo and behold! With a couple of simple gestures, the closing brace visually turns into an opening one.

This is an issue that PVS-Studio will highlight:

The PVS-Studio warning: V5901. OWASP. Code contains invisible characters that may alter its logic. Consider enabling the display of invisible characters in the code editor.

This vulnerability is listed in the OWASP standard, and our other analyzers can detect similar issues:

V5801 — JS\TS;
V5340 — Java;
V5629 — C#;
V1076 — C++.

We've covered this diagnostic rule in more detail in the documentation.

Is this the end? No, it's just the beginning!

The new analyzer for Go projects is here, but this is only the beginning of its story! The 40 diagnostic rules introduced with PVS-Studio 8.0 mark the start of that journey, and your input can make a real difference. If you're a Go developer, we invite you to try our tool for free. If you have ideas for new diagnostic rules or suggestions for improving the existing ones, feel free to reach out to us through the feedback form!

Thanks for reading. Take care of yourself and your code!

What's new in Java 27

Unicorn Developer — Tue, 15 Sep 2026 13:22:03 +0000

Java 27 is here, with four targeted updates and five previews/incubators. We take a closer look at the garbage collector changes, JFR improvements, post-quantum TLS 1.3, and compact object headers (which cut memory usage).

Java platform changes

JEP 534: Compact Object Headers by Default

Link to JEP

In the article about Java 25, we already mentioned compact object headers that we could turn on with a flag. Now there's no need to use the flag.

At that time, we only touched on this topic briefly. Now that it's on by default, we're going to break it down once again, in more depth.

Every object in the heap begins with a header. In the classic layout (in most JVMs), that's two blocks:

lock status, object's age for GC, identity hash;
a compact pointer to the class's metadata.

In total, we get 96 bits (12 bytes) per object, even if it contains very little useful data. Compact object headers compress all of this into 64 bits: the pointer to the class metadata is compressed down to 22 bits.

In theory, saving a few bits is a good thing, though, but what benefits shall we (as JRE users) actually get out of it?

Not long ago, we released a JavaScript/TypeScript analyzer powered by Java 25. We'll use it as a test subject, "set it loose" on the Grafana source code, and run it with and without compact object headers.

Three minutes later, we get this:

Benchmark	With flag	Without flag
Time	81.4 sec	79.4 sec
Committed heap	1 290 240K (~1.23 GB)	1 126 400K (~1.07 GB)
Used heap: output	1 150 092K (~1.1 GB)	773 062K (~738 MB)

Committed heap represents the amount of memory the virtual machine has allocated from the OS and is keeping reserved. Used heap is the memory in use right now—in other words, the number of bytes occupied by live objects that haven't yet been removed by the garbage collector.

As a result, analysis time remained almost unchanged (within margin of error), committed heap decreased by 13%, and used heap shrank by 33% in total! Just one flag reduced our app's memory usage by a full third, wow!

What's the cost of our joy? A 22-bit pointer limits the number of loaded classes to approximately four million. There's no automatic rollback to a non-compact mode—if the limit is exceeded, we'll get an OutOfMemoryError. If your app really hits this limit, you must really love long-lived streams. But if you want to revert to the previous mode, you can do it with another flag:

java -XX:-UseCompactObjectHeaders Application

JEP 523: Make G1 the Default Garbage Collector in All Environments

Link to JEP

Prior to Java 27, the JVM would check the machine at startup, and if it detected fewer than two processors or less than 1,792 MB of memory, it'd just use Serial GC instead of G1. That kind of machine got labeled a "client" machine, and the memory allocator best suited for it was used.

Now, guess what a modest JVM container with a limit of one CPU and 512 MB of memory looks like?

Right. A chunk of containerized Java apps has been running on a client-oriented collector all this time, even though no one consciously made that decision. Worse yet, the same app could get different GCs on the server and in the developer's IDE, which turned reproducing pausing issues into a thrilling quest with a touch of manic laughter.

Java 27 stopped taking the environment into account and now G1 is selected by default:

# Java 25
$ java -XX:ActiveProcessorCount=1 -Xmx256m -Xlog:gc --version
[0.001s][info][gc] Using Serial

# Java 27
$ java -XX:ActiveProcessorCount=1 -Xmx256m -Xlog:gc --version
[0.001s][info][gc] Using G1

The reasoning is simple: improvements to G1's throughput in previous releases have reduced the gap with Serial to almost zero, and G1's pauses are noticeably more pleasant because it can operate concurrently and in parallel. Plus, predictability: the application's behavior no longer depends on how many cores the JVM detected at startup.

If you specifically want to use Serial—it still has the lowest memory footprint and faster startup time—you can still use it: -XX:+UseSerialGC.

Security

JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3

Link to JEP

Ever heard of "harvest now, decrypt later"?

This is an amusing category of threats, though: attackers, having access to your traffic but unable to break the TLS connection, simply save the encrypted traffic for later.

Why would they do that, what's the purpose? It's very curious: attackers have a strong faith in global progress and are waiting for a quantum computer capable of breaking elliptic curve key exchange. Medical and banking records, encryption keys, personal data—all of these will still be valuable ten years from now, so the scheme is quite viable.

Following HTTP/3 (see the previous article), support for TLS 1.3 is now available. The session key in TLS 1.3 now gets generated using two algorithms simultaneously: a classic elliptic curve key exchange plus a quantum-resistant algorithm. Such a pairing is called a hybrid group, and the point is that the connection remains secure as long as at least one of the two algorithms is still in service. So this update makes it pointless to wait for a quantum computer to arrive.

For the application, this is free in terms of code: javax.net.ssl automatically sets the hybrid group as the first in the preference list. If the other side supports it, the exchange gets a hybrid approach; if not, everything works as before. There's nothing to touch, unless you've manually set a list of groups via jdk.tls.namedGroups or SSLParameters::setNamedGroups.

But in some cases, we'll still have to pay a little extra: a TLS handshake costs about two KB more. For most applications, this goes unnoticed, but with millions of short connections in the traffic, you'll see it.

An important note: this JEP applies only to key exchange. Certificate signatures are still in the classic format, and this is a deliberate choice: it is impossible to forge a signature retroactively, but it is entirely possible to decrypt recorded traffic.

JFR enhancements

JEP 536: JFR In-Process Data Redaction

Link to JEP

When recording, JFR carefully preserves the entire process environment: environment variables, system properties, and command-line arguments. And that's where, as we all know, database passwords, tokens, and keys to everything tend to live. That's why sending a .jfr file to a colleague—and especially attaching it to a public issue—always came with a slight twinge of anxiety. In most cases, you shouldn't make .jfr files publicly available at all without cleaning them up first.

Starting with Java 27, JFR scrubs sensitive values within the JVM before they're passed to disk. And what does JFR consider to be sensitive data? By default, any environment variable or system property whose name matches one of these patterns gets replaced with [REDACTED]:

*api*key*      *auth*        *client*secret*  *credential*
*jaas*config*  *passphrase*  *passwd*         *password*
*private*key*  *pwd*         *secret*         *token*

Command-line arguments of the form --db-password qwerty123 are handled in the same way.

We can expand the list of properties using the -XX:FlightRecorderOptions:redact-key=+<your-pattern> flag.

It's worth understanding the limits here: the mechanism covers start events (environment variables, system properties, arguments, and JVM information) and is explicitly described as best-effort. It doesn't filter your app's events, exception messages, or child process command lines. In other words, .jfr has become significantly safer now, but not sterile in total. We're still worried, but not as much as before.

In preview

A few more JEPs have been included in the release as previews. We won't cover them for now, we'll wait for their final versions. Here are some links for you to explore on your own:

Conclusion

The full list of JEPs is here.

This was a minor release, and there was nothing here in the way of earth-shattering, 180-degree changes: they've updated the preview and polished up the platform. And that brings useful thing right out of the box for the JVM: objects on the heap are more compact, the garbage collector is the same for both the server and a tiny pod, JFR logs are no longer brimming with secrets, and TLS is preparing for a quantum future.

Essentially, this is preparation for the next LTS. Structured Concurrency is now on its seventh preview, primitives in patterns are in their fifth preview, and the Vector API is waiting for Valhalla. All of this is being finalized so that it can be delivered ready to go with Java 29. Well, for now, though, let's just update and get a more compact heap for free.

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

Unicorn Developer — Thu, 10 Sep 2026 13:43:08 +0000

When it comes to ORMs, most C# developers immediately think of the powerful Entity Framework Core or the lightweight Dapper. What about RepoDB and SqlSugar, though? While they may not be as well-known, these ORMs are actually being used in real-world projects and are still developing. Let's take a look at what issues we can uncover in their source code with the help of a static analyzer.

Introduction

It's hard to imagine a modern application without an ORM: this technology helps developers by reducing the amount of code they need to write and by eliminating the need to work directly with SQL.

The ORM manages all interactions with the database, including processing read and write queries, transactions, and object-to-SQL mapping. Errors in such tools can lead to serious consequences: from reduced performance to application malfunctions and even security issues.

In the .NET world, Entity Framework Core and Dapper are the industry standards. However, many less popular tools are also used in real-world projects. RepoDB and SqlSugar are among these ORMs.

In this article, we'll look at them through the lens of PVS-Studio static analyzer. Instead of comparing API capabilities or performance, we'll check the projects' source code for potential bugs and suspicious constructs.

SqlSugar

Let's move on to discussing the most exciting parts of the SqlSugar code. The source code comes from this commit.

The forgotten CancellationToken

Code fragment 1

public Task<int> ExecuteCommandAsync(string sql, object parameters, 
  CancellationToken cancellationToken) 
{
  this.CancellationToken = CancellationToken;
  return ExecuteCommandAsync(sql,parameters);
}

The PVS-Studio warning: V3005 The 'this.CancellationToken' variable is assigned to itself. AdoProvider.cs 1472

The CancellationToken auto-property is assigned its own value. Most likely, this property should be assigned the value of the cancellationToken parameter instead.

A pointless string check

Code fragment 2

private static void AppColumns(SqlInfo result, 
  ISugarQueryable<object> queryable, 
  string columnName)
{
  var selectPkName = queryable.SqlBuilder.GetTranslationColumnName(columnName);
  if (result.IsSelectNav) 
  {
    if (   result.SelectString != null 
        && !result.SelectString
                  .ToLower()
                  .Contains($" {selectPkName.ToLower()}
                              AS {selectPkName.ToLower()}"))            // <=
    {
      result.SelectString = result.SelectString + "," 
        + (selectPkName + " AS " + selectPkName);
    }
  }
  ....
}

The PVS-Studio warning: V3122 Lowercase string is compared with a different mixed case string. NavigatManager.cs 1131

Let's take a closer look at what's going wrong here. First, the result.SelectString string is converted to lowercase using the ToLower method, and then the resulting string is checked whether it contains $" {selectPkName.ToLower()} AS {selectPkName.ToLower()}". The substring we're looking for contains uppercase letters (AS). As a result, the Contains method will always return false.

To fix the code, we can simply convert all the characters to lowercase:

!result.SelectString
       .ToLower()
       .Contains($" {selectPkName.ToLower()} as {selectPkName.ToLower()}"))

Recurring conditions

Code fragment 3

public override string ToSqlString()
{
  ....
  if (it.InsertServerTime || it.InsertSql.HasValue()) 
  {
    return GetDbColumn(it,null);
  }
  object value = null;
  if (it.Value is DateTime)
  {
    ....
  }
  else if (   it.Value is int 
           || it.Value is long 
           || it.Value is short                                    // <=
           || it.Value is short                                    // <=
           || it.Value is byte 
           || it.Value is double)
  {
    return  it.Value;
  }

  ....
}

The PVS-Studio warning: V3001 There are identical sub-expressions 'it.Value is short' to the left and to the right of the '||' operator. QuestDBInsertBuilder.cs 89

Using the it.Value is short sub-expression twice is pointless. Perhaps short should be replaced with another type, such as decimal or float.

Code fragment 4

public static Func<string, object> GetTypeConvert(object value)
{
  if (   value is int 
      || value is uint 
      || value is int? 
      || value is uint?)
  {
    return x => Convert.ToInt32(x);
  }
  else if (   value is short 
           || value is ushort 
           || value is short? 
           || value is ushort?)
  {
    return x => Convert.ToInt16(x);
  }
  else if (   value is long 
           || value is long?                                       // <=
           || value is ulong? 
           || value is long?)                                      // <=
  {
    return x => Convert.ToInt64(x);
  }
  ....
}

The PVS-Studio warning: V3001 There are identical sub-expressions 'value is long?' to the left and to the right of the '||' operator. UtilMethods.cs 288

The developers used the value is long? condition twice here. Based on the code above, we can assume that the second identical condition should be replaced with value is ulong.

An unused parameter

Code fragment 5

private string GetName(ExpressionParameter parameter, 
                       MemberExpression expression, 
                       bool? isLeft, 
                       bool isSingle)
{
  if (isSingle)
  {
    return GetSingleName(parameter, expression, IsLeft);
  }
  else
  {
    return GetMultipleName(parameter, expression, IsLeft);
  }
}

The PVS-Studio warning: V3196 The 'isLeft' parameter is not utilized inside the method body, but an identifier with a similar name is used inside the same method. MemberExpressionResolve.cs 770

The isLeft parameter isn't used, but the method accesses a property whose name differs from the parameter name only in the capitalization of the first letter.

The developers might have wanted to use isLeft parameter of the GetName method intended of the IsLeft property.

The missing num

Code fragment 6

public string GetValue(Expression expression)
{
  var numExp = (expression as MethodCallExpression).Arguments[0];
  var num =1;
  if (ExpressionTool.GetParameters(numExp).Any()) 
  { 
    var copyContext = this.Context.GetCopyContextWithMapping();
    copyContext.IsSingle = false;
    copyContext.Resolve(numExp, ResolveExpressType.WhereMultiple);
    copyContext.Result.GetString();                              // <=
  }
  else 
  {
    num = ExpressionTool.DynamicInvoke(numExp).ObjToInt();
  }
  var take = (expression as MethodCallExpression); 
  if (....)
  {
    return "TOP " + num;
  }
  else if (this.Context is OracleExpressionContext)
  {
    return (HasWhere ? "AND" : "WHERE") + " ROWNUM<=" + num;
  }
  else if (....)
  {
    return "limit " + num;
  }
  else if (this.Context.GetLimit() != null)
  {
    if (this?.Context?.Case != null)
    {
      this.Context.Case.HasWhere = this.HasWhere;
      this.Context.Case.Num = num;
    }
    return this.Context.GetLimit();
  }
  else
  {
    return "limit " + num;
  }
}

The PVS-Studio warning: V3010 The return value of function 'GetString' is required to be utilized. SubTake.cs 64

The analyzer reports that the return value of the GetString method isn't used. At the same time, the GetString implementation reveals that the method only builds and returns a string representation of _Result. It doesn't modify the object's state or perform any actions whose results are used later in the code:

public string GetString()
{
  if (_Result == null) return null;
  if (IsUpper)
    return
  _Result.ToString()
         .ToUpper()
         .Replace(UtilConstants.ReplaceCommaKey,",")
         .TrimEnd(',');
  else
    return _Result.ToString()
                  .Replace(UtilConstants.ReplaceCommaKey, ",")
                  .TrimEnd(',');
}

So, the result of the GetString call is discarded in the current code. The developers probably forgot to use the return value when calculating num.

The surrounding code also supports this assumption: every return from the method uses the num variable. Following this logic, both branches of the first condition should calculate the same value and assign it to the num variable.

The correct code may look like this:

copyContext.Resolve(numExp, ResolveExpressType.WhereMultiple);
num = copyContext.Result.GetString();

RepoDB

Now let's look at some errors and issues in the RepoDB project. The source code comes from this commit.

Pointless checks

Code fragment 1

public static object GetValue(this ConditionalExpression expression)
{
  var test = expression.Test.GetValue();
  var trueValue = expression.IfTrue.GetValue();
  if (expression.Test.NodeType == ExpressionType.Equal)
  {
    return test == trueValue ? trueValue : expression.IfFalse.GetValue();
  }
  else if (expression.Test.NodeType == ExpressionType.NotEqual)
  {
    return test != trueValue ? trueValue : expression.IfFalse.GetValue();
  }
  else if (expression.Test.NodeType > ExpressionType.GreaterThan)
  {
    ....
  }
  else if (expression.Test.NodeType > ExpressionType.GreaterThanOrEqual)// <=
  {
    ....  
  }
  else if (expression.Test.NodeType > ExpressionType.LessThan)          // <=
  {
    ....
  }
    else if (expression.Test.NodeType > ExpressionType.LessThanOrEqual) // <=
  {
    ....
  }
    throw new NotSupportedException(....);
}

The PVS-Studio warnings:

V3022 Expression 'expression.Test.NodeType > ExpressionType.GreaterThanOrEqual' is always false. ExpressionExtension.cs 456
V3022 Expression 'expression.Test.NodeType > ExpressionType.LessThan' is always false. ExpressionExtension.cs 460
V3022 Expression 'expression.Test.NodeType > ExpressionType.LessThanOrEqual' is always false. ExpressionExtension.cs 464

In the GetValue method, expression.Test.NodeType is successively compared against different values from the ExpressionType enumeration. However, the last four checks use the > operator instead of the equality operator.

The else if chain executes sequentially, and the enumeration values in the lower branches are greater than those in the branches above them.

public enum ExpressionType
{
  ....
  GreaterThan = 15,
  GreaterThanOrEqual = 16,
  ....
  LessThan = 20,
  LessThanOrEqual = 21,
  ....
}

The expression.Test.NodeType > ExpressionType.GreaterThan condition covers all the conditions that follow.

So, if expression.Test.NodeType > ExpressionType.GreaterThan evaluates to true, the subsequent conditions aren't checked. If it evaluates to false, the following conditions are false.

A copy-paste error

Code fragment 2

public override int GetHashCode()
{
  // Make sure to return if it is already provided
  if (this.hashCode != null)
  {
    return this.hashCode.Value;
  }

  // Get first the entity hash code
  var hashCode = HashCode.Combine(base.GetHashCode(), Name, ".UpdateAll");

  // Get the fields
  if (Fields != null)
  {
    foreach (var field in Fields)                           // <=
    {
      hashCode = HashCode.Combine(hashCode, field);
    }
  }

  // Get the qualifier <see cref="Field"/> objects
  if (Fields != null)                                       // <=
  {
    foreach (var field in Qualifiers)
    {
      hashCode = HashCode.Combine(hashCode, field);
    }
  }

  ....
}

The PVS-Studio warning: V3127 Two similar code fragments were found. Perhaps, this is a typo and 'Qualifiers' variable should be used instead of 'Fields'. UpdateAllRequest.cs 124

Fields is checked for null twice. Most likely, the second check should use Qualifiers instead of Fields, since this collection is used in foreach.

Code fragment 3

public static Task<int> UpdateAllAsync<TEntity>(....
    Expression<Func<TEntity, object>> qualifiers,
    ....,
    IEnumerable<Field> fields = null,
    ....)
    where TEntity : class
{
  return UpdateAllAsyncInternal<TEntity>(connection: connection,
    tableName: tableName,
    entities: entities,
    qualifiers: fields,                                      // <=
    batchSize: batchSize,
    fields: fields,                                          // <=
    hints: hints,
    commandTimeout: commandTimeout,
    traceKey: traceKey,
    transaction: transaction,
    trace: trace,
    statementBuilder: statementBuilder,
    cancellationToken: cancellationToken);
}

The PVS-Studio warning: V3038 The argument was passed to method several times. It is possible that other argument should be passed instead. UpdateAll.cs 619

Here, the fields parameter is passed to the UpdateAllAsyncInternal method twice, while the qualifiers parameter isn't used at all.

The developers might have wanted to pass qualifiers as follows:

qualifiers: Field.Parse<TEntity>(qualifiers)

An empty collection

Code fragment 4

public override string CreateBatchQuery(string tableName,
  IEnumerable<Field> fields,
  int page,
  int rowsPerBatch,
  IEnumerable<OrderField> orderBy = null,
  QueryGroup where = null,
  string hints = null)
{
  // Ensure with guards
  GuardTableName(tableName);

  // Validate the hints
  GuardHints(hints);

  // There should be fields
  if (fields?.Any() != true)
  {
    throw new MissingFieldsException(fields?.Select(f => f.Name));
  }
  ....
}

The PVS-Studio warning: V3191 Iteration through the 'fields' collection makes no sense because it is always empty. SqlServerStatementBuilder.cs 70

The fields?.Any() != true condition is true when the fields collection is empty or null. In that case, fields?.Select(f => f.Name) serves no purpose, as it will always return an empty collection or null.

The treacherous null

Code fragment 5

public override Guid GetGuid(int i)
{
  ThrowExceptionIfNotAvailable();
  return Guid.Parse(GetValue(i)?.ToString());
}

The PVS-Studio warning: V3105 The result of null-conditional operator is passed as the first argument to the 'Parse' method and is not expected to be null. DataEntityDataReader.cs 405

Here, GetValue(i) may return null, which will be passed to the Guid.Parse method because of the ? operator. And Guid.Parse will throw an ArgumentNullException when passed the null argument.

Code fragment 6

public static void AssertMembersEquality(
  object obj, 
  IDictionary<string, object> dictionary)
{
  ....
  var value1 = property.GetValue(obj);
  var value2 = dictionary[property.Name];
  if (value1 is byte[] b1 && value2 is byte[] b2)
  {
    ....
  else
  {
    var propertyType = property.PropertyType.GetUnderlyingType();
    if (propertyType == typeof(TimeSpan) && value2 is DateTime dateTime)
    {
      value2 = dateTime.TimeOfDay;
    }
    else if (propertyType == typeof(string) && value2 is DateTime)
    {
      value1 = DateTime.Parse(value1?.ToString());                // <=
    }
  ....
}

The PVS-Studio warning: V3105 The result of null-conditional operator is passed as the first argument to the 'Parse' method and is not expected to be null. Helper.cs 157

Again, if value1 is null, the ArgumentNullException will be thrown.

Conclusion

Despite the substantial amount of code and extensive functionality of the projects, the analysis revealed only a few suspicious code fragments. This suggests that both projects are well written and maintained at a high standard.

Still, perfect code doesn't exist. Even mature and popular libraries can contain copy-paste errors, forgotten parameters, incorrect conditions, and other minor issues that are easy to overlook during development and testing. This is where static analysis is particularly useful: it can highlight potential issues before they become real problems.

If you'd like to analyze your own project with PVS-Studio, you can try it via this link.

Take care of yourself and your code!

Bugbusters podcast #1: Is C++ still worth learning in 2026?

Unicorn Developer — Thu, 10 Sep 2026 07:53:46 +0000

C++ has been around for decades, and it’s still everywhere: game engines, embedded systems, operating systems, high-performance software, and plenty of codebases that aren’t going anywhere anytime soon.

But does that make C++ a good language to learn today? Where is the language heading? What makes it worth the effort, and what are the drawbacks developers have to live with?

In the first episode of the Bugbusters podcast, Yuri Minaev and Nathan Baggs discuss these questions and a few others about learning and working with C++ in 2026.

Watch the full episode

Webinar: Let's make a programming language. Evaluator

Unicorn Developer — Wed, 09 Sep 2026 12:36:34 +0000

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

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

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

Join us live to dive deeper into language implementation, ask your questions, and see how the final pieces of the puzzle come together.

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

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

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

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

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

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

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

Sixth talk: Let's make a programming language. Variables

Seventh talk: Let's make a programming language. Functions

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.

Join us on September 24th, 1:00 PM UTC+1!

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

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

Unicorn Developer — Tue, 08 Sep 2026 14:22:42 +0000

PVS-Studio analyzer already provides dozens of integrations with various tools and services, and in this article, we'd like to explain why.

We develop and sell PVS-Studio static analyzer with a wide variety of features such as command-line utilities, diagnostic rules in various categories, support utilities, and so on.

Behind "so on", we usually mean numerous integrations with third-party tools (plugins, extensions, and usage scenarios). But why do we hide them? You can see that by yourself: the first PVS-Studio integration was a plugin for Visual Studio 2005, released 18 years ago. Today, the analyzer integrates with more than three dozen other development tools: IDE plugins, game engines, code quality platforms, build systems, CI/CD platforms, and more.

Keeping all these integrations up to date and working properly takes a lot of effort, and now we'll explain why we do it in the first place.

Convenience of use

The most daunting thing when you think about integrating a new tool is the complexity of the implementation process. What's more, this feeling arises among both managers and engineer—don't forget about the principle of "If it works, don't touch it".

And it's okay because every company or team has its own approaches and tools, and when it comes to implementing something new, it seems complicated. And often it's not just about inner feelings—the implementation process is often quite complex.

Actually, that's the main reason we're working to develop integrations for popular tools. If you're already using a specific set of IDEs or a particular web dashboard for DevSecOps, why force you to use something we've come up with? Instead, we suggest expanding the familiar set of features to include the ability to use our tool.

Also, different people on the team may need different tools: developers search for the easy run of the static analyzer during development, and manager would like to quickly view warnings' statistics in a web dashboard. That's why we're creating so many integrations.

Usage scenarios

Yes, the static analyzer doesn't usually seem like a hard-to-use tool, but its initial configuration varies greatly depending on the project and the required use cases.

Let's take a look at some use cases using specific examples.

On-premise analysis

The static analyzer runs on developers' machines so they can check their code before the commit to the version control system.

It may seem that a fairly straightforward and user-friendly CLI would be enough—we're engineers, after all. But in reality, "to each his own". Some people prefer a specific IDE, while others would sell their souls for Vim.

We need to know how to work with all of this, that' why PVS-Studio offers plugins for all the most popular IDEs used for development in the languages supported by our analyzers:

It might seem like all this isn't worth the effort, but IDE plugins can significantly reduce the time it takes to go from an idea to a result: open a project, click a button, and get the analysis results in just a few seconds or minutes.

As a result, we move all the tedious but important part of integration from the user to our tool: we ask the build system what language, type, and specifics of the project is here, then obtain a list of files for analysis, apply the main settings; display the progress and results; and provide user-friendly access to auxiliary tools.

For example, one way to suppress false positives is to use special comments in the code. If you're working from the terminal, you have to build the whole new process:

find the warning position in the report file;
go to that line in the file;
add a comment with the diagnostic rule number;
~~try to remember how to exit from Vim~~.

It's not exactly difficult. The IDE plugins streamline this path to just a couple of clicks, without having to read the documentation or switch between tools.

If the IDE integration isn't an option, integrations with build systems can help. For example, you can configure the analysis of Java projects using integrations with Gradle and Maven, and for CMake, there are actually two integrations: one using our CMake module and one using the utility's own built-in mechanisms (official Kitware integration was added in version 4.3.0).

We wrote about the official integration into CMake in a separate article.

Continuous integration

The next major step in using static analysis is to integrate it into CI for automatic analysis updates. This stage involves a wide range of implementation options, which is why the list of integrations here is quite diverse.

For example, among on-premises solutions, there are integrations with Jenkins and TeamCity; among cloud-based solutions, there are GitHub Actions and GitLab CI/CD.

For automation, it may also be helpful if the tool can run in containerization and virtualization environments, such as Docker and WSL.

By the way, automatically running static analysis is important not only in CI but also for regular analysis.

Regular analysis

The regular analysis periodically runs an analysis of the entire project during nightly builds that helps determine whether there are any errors in the project as a whole, because during local analysis and in CI, we usually check only individual updates.

This stage, in addition to the mentioned integrations, requires web dashboards and code quality monitoring systems: the entire project is analyzed on the server, and we need to ensure that the whole team can collaborate on the resulting report.

Plus, this collaborative work involves both reviewing the report and marking up warnings. Managers, meanwhile, can use various metrics to track the results and distribute the work among team members.

A code quality monitoring platform serves as a centralized repository of information on how code quality has changed over time within a project, which is why this tool is of practical use to managers.

Among its web dashboards, PVS-Studio supports integrations with SonarQube, DefectDojo, and CodeChecker.

Specific usage scenarios

We don't forget about development specializations. Why does it matter? The reason is the same as before, we just integrate into other tools that are specific for a certain dev area.

The first specialization that PVS-Studio supports is game development. For game dev projects, we support integrations with Unreal Engine and Unity.

Our tool can be also involved into development of embedded systems. Due to the nature of embedded systems, there's a huge variety of compilers, and they can differ significantly from one another. That's why we strive to make sure the analyzer works with the compilers and SDKs our customers use, including IAR Embedded Workbench, QNX Momentics, Keil µVision, Texas Instruments Code Composer Studio, and others. You can always find the complete list on the website.

Conclusion

We hope we've managed to explain that integrations for PVS-Studio aren't just a checkbox in a checklist—it makes static analysis a convenient and seamless part of the user's workflow.

We use these tools to make static analysis a convenient and seamless part of the workflow.

From our very first Visual Studio 2005 plugin to the present day, we've been working to make PVS-Studio go where our users work.

If you haven't tried testing your project with our analyzer yet, you can start on this page.

And if you're already using PVS-Studio and have something to say about it, you can write to us using this form. For example, we'd be interested to know what integrations you feel are missing from the product.

Clean code to you, folks!

The worst programming language of all time /s

Unicorn Developer — Fri, 04 Sep 2026 14:17:09 +0000

In this article, the author looks at why C++ feels so complicated, and why its flaws are inseparable from its long-term success.

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

There's a video on YouTube—a little over fifty minutes long, with a rather bold title: "The worst programming language of all time." I wouldn't be surprised if you assumed it was about C++. You'd be right. I first watched it about six months ago—or rather, skimmed it at 2x speed with plenty of skipping. I figured it was just another rant from a frustrated junior developer. Recently, though, a fellow community member brought it up again, so this time I watched the whole thing. And you know what the worst part is? If you focus purely on the substance and set aside the tone of an offended junior dev, about 70% of the arguments turn out to be valid. Not debatable, not "it depends on the context." Just plain facts that almost any developer who's spent a couple of years with C++ would confirm without hesitation.

The paradox is that the video takes aim at the language behind half the software around us. That includes the browser you're reading this in, the engine that powered the game you played yesterday, the firmware running on the hardware underneath, and even the compiler that built all of it.

The "C++ is terrible" narrative has been a cliché forever. You've probably read dozens of articles about the initialization-order fiasco, the overloaded static, the poorly named vector, the fact that std::move doesn't actually move anything, the painfully slow regex, and the underwhelming performance of unordered_map. None of these complaints are new. What I'd like to point out is that every issue and example I cover below stems from the same fundamental design decision. If you can't wait, open the spoilers—they explain the history behind each part of the language and why it turned out the way it did.

There's more than one way to initialize a variable

Let's start with the deepest circle of hell—the beginning of every program: creating a variable. In most languages, that's a single, straightforward operation. In C++, however, people write entire books about it. They publish research papers, give conference talks, and dissect every corner case as if the language didn't have enough other problems already. Did I miss anything? Please let me know.

int f;                    // automatic storage, garbage
static int f_static;      // but the namespace/static scope already has zero 
                          // (zero-init in the beginning)

std::string s;            // a call to the default constructor
int* p = new int;         // a heap, garbage
int e{};                  // 0
int e2 = {};              // 0
int* p = new int{};       // 0
int* q = new int();       // it's 0 too
auto t = T{};             // temporary, value-init
int b(5);
std::string s("hello");
T obj(a1, a2);
auto p = new T(a1, a2);
int x = static_cast<int>(3.5);   // a cast, it's also a direct-init
int y(int(5));                   // functional notation
int a = 5;
std::string s = "hello";
T obj = other;
f(arg);                   // pass by value; the function's 
                          // PARAMETER is initialized

                          // an invisible variable
f({1, 2, 3});             // same
return x;                 // return by value
return {1, 2, 3};         // same, if copy-elision doesn't work
throw x;                  // an exception object is initialized
int c{5};                 // direct-list
int d = {5};              // copy-list
std::vector<int> v{1, 2, 3};
std::vector<int> v2 = {1, 2, 3};
std::vector<int> a(10);   // 10 elements, all zeros
std::vector<int> b{10};   // ONE element has a value of 10
struct Point { int x, y; };
Point p{1, 2};            // you can do it this way
Point p2 = {1, 2};        // or you can do it that way
int arr[3] = {1, 2, 3};   // with or without zeros
int arr2[3] = {};         // all zeros
Point p3{.x = 1, .y = 2}; // designated initializers, C++20
Point p4{1};              // x=1, y=0 (value-init tail)
int& r = x;
const int& cr = 5;        // linked to temporary + extending lifetime
int&& rr = 10;
constexpr int n = 42;     // it must be constant-init
const int m = foo();      // it can be either constant or dynamic
constinit int g = bar();  // C++20: guarantees static-init, 
                          // but DOESN'T make it const
static int s = compute(); // dynamic-init, with its Static Init Order Fiasco
struct S {
    int x = 5;            // default member initializer
    int y{10};
    S() : y{2}, x(1) {}   // member initializer list 
                          // (in the order of declaration, not by list)
};
auto [a, b] = std::pair{1, 2};   // structured bindings, C++17
for (int v : arr) { }            // range-based for initializes v too

If we count the distinct initialization semantics, we end up with around ten different forms (= v, (v), {v}, = {v}, {}, = {}, () in new, and so on). These map to nine different semantic categories, and the relationship between syntax and semantics is far from one-to-one. Depending on the right type, the same {} syntax can mean value-init, list-init, or aggregate-init. There's even a dedicated 300-page book on C++ initialization—and no, this isn't a joke. A friend once recommended it to me. It really exists, and it really is 300 pages long. Enjoy.

Every initialization form behaves just a little differently. My favorite is the difference between e and f, where the presence or absence of a pair of braces determines whether your variable holds zero or whatever bits the previous function call left on the stack.

struct S {
    int x = 5;     // default member initializer
    int y{10};
};

NSDMI stands for Non-Static Data Member Initializer—an initializer for a non-static data member written directly in the class definition. When we write int x = 5;, no object exists yet, so nothing is initialized. What we have instead is a default member initializer, a fallback the compiler uses during object construction ONLY IF the constructor doesn't initialize that member in its mem-init-list. In other words, it's a recipe for default initialization, not an actual initialization. Technically, it's a brace-or-equal-initializer for a member.

auto [a, b] = std::pair{1, 2};

Here the compiler initializes a hidden unnamed object (commonly called the hidden object or the decomposition object—let's call it e). The names a and b aren't independent variables; they're bindings to parts of that unnamed object. The initialization applies to e, not to a or b. It's a subtle distinction, but since we're being precise, it's worth pointing out again that they aren't real variables so much as structure members, and that e isn't directly accessible. The storage, however, looks roughly like this:

e
+---------+
| first   | <--- a
| second  | <--- b
+---------+
auto e = std::pair{1, 2};
auto& a = e.first;
auto& b = e.second;

Asm

int k, e;

int main() {
    auto [a, b] = std::pair{k, e};

    return a + b;
}
----------------------------------------

leaq    -12(%rbp), %rdi
leaq    k(%rip), %rsi
leaq    e(%rip), %rdx
callq   std::pair<int, int>::pair<int&, int&, true>(int&, int&)

This is where a hidden structured binding object is created. The rdi argument is the first argument to the constructor—that is, the address of where pair is constructed.

main:
        pushq   %rbp
        movq    %rsp, %rbp
        subq    $32, %rsp
        movl    $0, -4(%rbp)
        leaq    -12(%rbp), %rdi  <<<<<
        leaq    k(%rip), %rsi    <<<<<
        leaq    e(%rip), %rdx    <<<<<
        callq   std::pair<int, int>::pair<int&, int&, true>(int&, int&) <<<<<
        leaq    -12(%rbp), %rdi
        callq   tuple_element<0ul, std::pair<int, int>>::type && 
                              std::get<0ul, int, int>(std::pair<int, int>&&)
        movq    %rax, -24(%rbp)
        leaq    -12(%rbp), %rdi
        callq   tuple_element<1ul, std::pair<int, int>>::type && 
                              std::get<1ul, int, int>(std::pair<int, int>&&)
        movq    %rax, -32(%rbp)
        movq    -24(%rbp), %rax
        movl    (%rax), %eax
        movq    -32(%rbp), %rcx
        addl    (%rcx), %eax
        addq    $32, %rsp
        popq    %rbp
        retq

k:
        .long   0

e:
        .long   0

And just when we think we've got it, we find out that braces can mean aggregate initialization in one context and std::initializer_list in another, and that the same line of code may yield a different type depending on which version of the standard you compile against. Not a different result—a different type. Welcome to C++.

auto i = 1;      // always int
auto j = {1};    // initializer_list<int> is always (copy-list-init)
auto k{1};       // C++11: initializer_list<int>;  C++17+: int

The origin of the zoo

The initialization zoo grew out of an attempt to eliminate... the initialization zoo! In 2011, the committee genuinely tried to unify everything under a single syntax. Instead, it added one more enclosure to the zoo.

From C, C++ inherited initialization for declarations (int a = 5;) and braces for aggregates such as arrays and structs (int arr[] = {1,2,3};). In C, braces simply distributed values across the members of a POD aggregate. They were never meant to do anything else.

Then C++ introduced constructors. Once they existed, they needed a way to run when an object was created. Parentheses felt like the most natural choice, since a constructor call looks a lot like a function call—hence Widget w(args);. Makes sense? Absolutely.

Right up until the day you write Widget w(); and realize you've declared a function returning Widget. That's the infamous most vexing parse. It isn't an implementation bug but a direct consequence of the grammar inherited from C, where declarations are designed to resemble usage. That design also makes a function declaration syntactically indistinguishable from constructing an object with empty parentheses.

Then came C++11 and its great invention: uniform initialization. The goal was admirable—introduce a single syntax, {}, that works everywhere, whether you're initializing aggregates, classes with constructors, scalars, or containers.

As a bonus, it would eliminate the most vexing parse, because Widget w{}; can never be parsed as a function. It would also reject narrowing conversions: int x{3.5}; is a compilation error, whereas int x = 3.5; silently truncates the fractional part.

In other words, {} wasn't meant to become yet another initialization syntax. It was supposed to be the initialization syntax—the one true way that would eventually replace all the others.

This is where we run into the issue that explains so much about C++. To make {} the only syntax, the language would have had to drop = and (). But those appear in billions of lines of code—engines, libraries, and third-party APIs all rely on them.

So the old syntax couldn't be removed, and the new universal syntax didn't replace the older ones; it simply found a niche of its own, and now we have even more options. The feature meant to shut down the zoo became its most famous exhibit.

To make things even more entertaining, braces later picked up a second meaning through std::initializer_list. If a type has a constructor taking an initializer list, braces select it, and it takes precedence in overload resolution.

The difference between int e{}; (zero) and int f; (garbage) is a separate story. That behavior comes from C, where automatic variables were never zeroed by default. This wasn't an oversight but a deliberate design choice: zero-initialization costs CPU cycles, and C's philosophy has always been "you don't pay for what you don't use." If you wanted zero, you were expected to write it yourself.

That's why int f; leaves behind bits from the previous function call's stack frame. It's by design—a feature dating back to C, around 1972. Later, Stroustrup wanted to offer a safe, zero-initialized default, but he couldn't make it the language default without breaking both backward compatibility and C's core philosophy of "don't pay for what you don't use." So the safe option exists, but it isn't the default, because the default was fixed half a century ago in the name of performance.

At this point, unifying everything under a single initialization syntax is impossible. Every form has accumulated its own code, semantics, and rules. So when yet another 300-page book on C++ initialization appears—or someone presents a flowchart that takes up half the screen—that isn't the authors showing off. It's the price of everything that's been put into the language over the past forty years, all because of its most defining feature.

Simple things are the hardest to do

A textbook example of needlessly complicated simplicity is generating a random number. In Java or Python, you'd just write something like random.randint(1, 100) and get on with your code. Not in C++, though. That would be far too simple.

std::random_device rd;
std::mt19937 gen(rd());                          // what's mt19937?
std::uniform_int_distribution<int> dist(1, 100); // why is it separated?
int value = dist(gen);                           // finally

The code is readable enough, but I still found myself checking CppReference every other time I needed to. Then I had to Google what mt19937 actually is. Turns out it's the Mersenne Twister. Congratulations—you now know the name of a pseudorandom number generator. Apparently, that's knowledge you're expected to have just to roll a die in C++.

Simple things

Before C++11, the language relied on rand(), inherited from C. It returns a number in a range bounded by RAND_MAX—a value the standard guarantees to be at least 32,767. On some platforms, that makes it impossible to get a uniformly distributed number across a wide range.

The familiar rand() % 100 introduces modulo bias, because 100 doesn't evenly divide the number of possible outputs. Some values come up more often than others, and the resulting sequence isn't even reproducible across compilers. In other words, rand() was a wonderfully simple way to shoot yourself in the foot.

That's why C++11 adopted an entirely new design borrowed from Boost.Random—one that deliberately pulled apart everything rand() had lumped together. Now there's the engine itself, the source of raw random bits (mt19937, a.k.a. the Mersenne Twister, designed by Matsumoto and Nishimura in 1997). Then there's a distribution that turns those raw bits into uniformly distributed values over a given range without introducing bias. And finally there's a separate seed source.

This design came from people who needed reproducible Monte Carlo simulations for scientific computing, and for that use case it worked brilliantly. The problem is that they built a magnificent cathedral and never bothered to add a small side door for "roll a number between 1 and 100." To this day, the C++ standard library offers no one-line randint().

Even the "correct" incantation isn't actually correct, though. First, mt19937 carries nearly 20,000 bits of internal state, yet we usually seed it with a single 32-bit value from std::random_device. In other words, we're severely undersowing the generator.

Then there's std::random_device itself. The standard explicitly permits implementations to make it deterministic, and for years older MinGW versions returned the same sequence on every program start. So the long, supposedly correct spell is indeed long, and technically correct but it still doesn't work reliably everywhere. Meanwhile, rand() % 100 is shorter and actually works.

Casting problems

Casting is a whole different story. In Java, we just put the target type in parentheses and move on. In C++, we get an entire collection of casts, each built for a specific purpose: static_cast, dynamic_cast, reinterpret_cast, const_cast, bit_cast—every one with a full name you have to spell out each time. There's also the hidden rvalue_cast, but we'll get to that in a moment.

double d = 3.9;
int i = static_cast<int>(d);        // 3, the decimal part is omitted

Base* b = new Derived;
auto* der = static_cast<Derived*>(b); // downcast WITHOUT checking 
                                      // you guarantee that it's Derived

Base* b = get_something();
if (Derived* d = dynamic_cast<Derived*>(b)) {
    d->derived_only();              // you can get here only if it's Derived
}                                   // otherwise d == nullptr

// an address as a number
int x = 42;
std::uintptr_t addr = reinterpret_cast<std::uintptr_t>(&x);

void legacy_api(char* s);    // It didn't modify the line but missed const

const std::string str = "hello";
legacy_api(const_cast<char*>(str.c_str()));  // it's OK, 
                                             // since the API isn't modified

float f = 1.0f;
auto bits = std::bit_cast<std::uint32_t>(f);  // 0x3F800000, no UB

// how they did it before C++20:
std::uint32_t old;
std::memcpy(&old, &f, sizeof f);              // the same thing but manually

int i = (int)d;                     // it compiles and looks familiar

Beginners often find this so frustrating that they end up creating a short alias. This is considered poor practice because the code is written in a personal C++ dialect that only the creator understands.

// the "I'm tired of writing static_cast" anti-pattern
template <class T, class U>
constexpr T sc(U&& u) { return static_cast<T>(std::forward<U>(u)); }

int i = sc<int>(3.9);               // is it short? yep. 
                                    // is it correct? nope.

// it may be even worse:
#define CAST(T, x) static_cast<T>(x)

This is where the language really starts to mess with you. Correct C++ often looks incorrect, because the short, elegant solution is usually buggy or subtly flawed, while the correct one looks like the author went out of their way to make life harder for everyone on the team. Developing an intuition for what good C++ code looks like takes years. Until then, it feels like you're constantly doing something wrong. Spoiler: you probably are—that's just how the language works.

Why so chonky?

C has the (T)expr C-style cast, and it does everything. It can change values, reinterpret pointers, strip const, narrow types, and more—all with exactly the same syntax. The result is that nowhere in a codebase can you tell where someone cast away const, because those casts look identical to any other conversion.

C++ split this "Swiss Army knife" into four named operations—static_cast, dynamic_cast, const_cast, and reinterpret_cast—precisely because in C they were indistinguishable.

The point was to make the intent explicit and to ensure that const_cast, which undermines const, would catch a reviewer's eye. The idea was to make casts easy to grep, so a programmer could find and inspect every reinterpret_cast in a codebase.

Casts are treated as a necessary evil, so the language designers deliberately made them ugly. As Andrei Alexandrescu famously put it, a cast is a code smell. Stroustrup intentionally chose a verbose syntax so that explicit casts would be painful to type and would stand out immediately in code review. The old C-style cast was too lightweight, and that's exactly what made it so dangerous.

That's why the correct solution in C++ so often looks wrong—not by accident, but by design. The short, elegant version is usually broken legacy that can't be removed because of the language's most important feature: backward compatibility. The correct one is deliberately wordy and awkward. Its purpose is to make you stop and think about every explicit conversion you write.

Keywords that lie

In a sane world, a keyword describes what it does. In C++, that's more of an optional feature. Take static, for example.

How many meanings does it have again? First, it creates a variable that survives between function calls. Second, it makes a variable or member function belong to all instances of a class. Third, placing static before a function in a .cpp file makes that function invisible from the outside, so it behaves like private but is named static. Why not internal, private, or file_local? Well, that's just how things are, which answers about half of the questions in this article.

void counter() {
    static int calls = 0;   // it's initialized ONCE, on the first entry
    int local = 0;          // a normal local; each call is made anew
    ++calls;
    ++local;
    std::cout << "static: " << calls << ", local: " << local << '\n';
}

The static keyword, which was introduced after C++11, now implies that static also means light mutex-guarded. Did you know that?

Logger& logger() {
  static Logger instance;   // a one line
  return instance;
}

Logger& logger() {
  // the QUICK way: if the least significant byte of guard != 0, 
  // it's already been initialized
  if ((reinterpret_cast<volatile char&>(__guard_for_instance)) == 0) {

    // the SLOW way: we only go this way the first time, 
    // and only when we're in sync
    if (__cxa_guard_acquire(&__guard_for_instance)) {
      // `acquire` returned 1, 
      // so this thread is responsible for initializing it
      // the other threads are currently SLEEPING inside __cxa_guard_acquire
      try {
        ::new(&__instance_storage) Logger(); //the call to the constructor
         __cxa_guard_release(&__guard_for_instance);  // we set the flag
                                                      // and wake the sleepers
         __cxa_atexit(&destroy_logger, ...); // we register the destruction
      } catch (...) {
        __cxa_guard_abort(&__guard_for_instance);      
        throw;
      }
    }
    // the threads that lost the race left the acquire block after release
  }
  return reinterpret_cast<Logger&>(__instance_storage);
}

Why static does four unrelated things

In C, static already had two distinct meanings. The first and more familiar one controls storage duration—the variable exists for the entire lifetime of the program.

The second controls internal linkage, meaning the name isn't visible outside the translation unit. Semantically, these two ideas have almost nothing in common: one is about object lifetime, the other about symbol visibility. Yet K&R folded them into a single keyword. Their reasoning was simple: C should have as few keywords as possible, and static was close enough to "statically allocated."

C++ inherited both meanings unchanged. Dropping either one would have meant breaking compatibility with C—exactly the outcome the language was trying to avoid. Later, when Stroustrup introduced class members shared by all instances, he could have added a new keyword such as shared or classwide, or something descriptive in the spirit of private and protected. But by then it was already clear that every new keyword added to the language was a potential landmine for developers.

By that point, someone somewhere had almost certainly named a variable shared, internal, or classwide. The moment one of those words became a keyword, their code would stop compiling. That's why the language designers tried to reuse existing keywords wherever possible instead of inventing new ones. And since static was already in the language, its meaning was already somewhat overloaded—one more interpretation didn't risk breaking anyone's production code. So static picked up a third meaning, not because it was the best semantic fit, but because the keyword was already there, and reusing it preserved backward compatibility.

A fourth behavior arrived with C++11, when initialization of function-local static variables was made thread-safe. To pull that off, compilers began emitting a hidden guard that ensures initialization happens exactly once.

There was one attempt to clean things up. In C++98, using file-scope static for internal linkage was officially discouraged in favor of unnamed namespaces. But C++11 walked that recommendation back, because breaking developers' long-standing habits proved more costly than changing the language. In other words, C++ couldn't get rid of a meaning it had already declared obsolete.

Realistically, none of the four meanings can be removed now. Each has code depending on it—a local counter, a private helper function, or a class member that's part of a public API used by hundreds of thousands of developers.

The inline keyword once prompted the compiler to inline a function. Today, compilers are smart enough to decide on their own, and inline has mostly become a tool for dealing with linkage and the One Definition Rule. To make things stranger, inline means almost the opposite depending on what you apply it to: for a function, it allows code duplication, while for a variable, it prohibits data duplication.

// math.h
inline int square(int x) { return x * x; }

// a.cpp
#include "math.h"
int use_a() { return square(3); }

// b.cpp
#include "math.h"
int use_b() { return square(4); }

// counter.h
inline int g_calls = 0;   // there's only one instance for the entire program

// a.cpp
#include "counter.h"
void hit_a() { ++g_calls; }

// b.cpp
#include "counter.h"
void hit_b() { ++g_calls; }

// config.h
struct Config {
  static inline int instances = 0;  // there's one counter for all objects in .h
};

inline constexpr double kPi = 3.14159265358979; // its a header-only constant, 
                                                // a single object

What inline was designed for

In early C++, inline was a type-safe replacement for a #define macro. The idea was simple: instead of a function call, substitute the function body directly at the call site. It was literally an optimization based on inline expansion. That's where the name comes from, and that's why many developers still believe inline means "make this faster." That hasn't been true for at least the past fifteen years.

Today its primary purpose has little to do with optimization. Instead, inline is about the ODR and linkage. An inline entity may have definitions in multiple translation units—for example, when you put the definition in a header and include it everywhere. The linker then has to merge those definitions into a single entity rather than failing with a multiple definition error.

So what does inline have to do with actual inlining these days? Very little. As an optimization hint, it's purely advisory. Modern compilers routinely ignore it because they rely on sophisticated cost models. They'll happily inline functions that aren't marked inline and refuse to inline ones that are. With LTO enabled, they can even inline across translation-unit boundaries whether the keyword is there or not.

These days inline is only indirectly related to real inlining. Its actual job is to let you put a definition in a header without triggering linker errors—and the optimizer can keep the visible body in a separate TU, since LTO is impossible without it.

Member functions defined directly in a class body are implicitly inline. So are all constexpr functions. Yet developers still write the keyword just in case, even though it changes nothing.

Now we force inlining with __forceinline (MSVC) and __attribute__((always_inline)) or [[gnu::always_inline]]—and even those often fail in the presence of recursion, varargs, or taking a function's address. The name is a relic of a time when it really did work that way; now it's a message to the linker.

The const keyword is supposed to mean immutability, yet you can write it on either side of a type, and both forms mean exactly the same thing—just to keep you on your toes. It gets better: mutable const is sometimes valid code. You can also manually remove the constness. It's not ideal but technically possible.

The official advice for determining whether const in a pointer declaration applies to the pointer or to its value is to read it from right to left, but most people read from left to right.

const int a = 5;   // "west const"
int const b = 5;   // "east const" is exactly the same; both are constants

const int* p = &a; // the pointer to const int
int const* q = &a; // this is the same thing

struct Cache {
    mutable int hits = 0;   // can be changed even for a const object
    int value = 0;
};

const Cache c;
c.hits++;       // OK, mutable
// c.value++;   // this is an error; a regular member of a const object

struct S {
    mutable const int* p = nullptr;  // VALID
};

struct Bad {
    mutable const int x = 5;  // INVALID: mutable can't be used 
                              // on a const member
};

// Case 1: The object is ACTUALLY not const, OK
int x = 5;
const int& cref = x;
const_cast<int&>(cref) = 10;   // correct: x indeed changed, x == 10

// Case 2: the object is ACTUALLY const, Undefined Behavior
const int y = 5;
const_cast<int&>(y) = 10;      // it compiles, but it's UB
                               // y could stay at 5, drop, or anything else

int x = 0, y = 0;

const int* p1 = &x;        // p1: pointer to const int
int* const p2 = &x;        // p2: const pointer to int
const int* const p3 = &x;  // p3: const pointer to const int

*p1 = 5;   // error: const value
p1 = &y;   // OK: the pointer can be redirected

*p2 = 5;   // OK: the value can be changed
p2 = &y;   // error: const pointer

*p3 = 5;   // error
p3 = &y;   // error

Why use const if memory isn't const?

The const keyword originated in C++ and was later adopted by C, not the other way around. Stroustrup introduced it back in "C with Classes"—initially under the working name readonly. From there it made its way into the C89 standard and took on a life of its own. Ironically, the keyword created to bring order immediately inherited the quirks of the grammar it was dropped into.

First, const int and int const are literally the same thing: const is a type qualifier living in the decl-specifier-seq, the sequence of declaration specifiers.

That sequence was unordered long before const came along, for the same reason unsigned long and long unsigned name the same type. So const inherited an old quirk: the order of specifiers already didn't matter. The more consistent form is actually int const, because const conceptually applies to whatever sits immediately to its left. The alternative, const int, exists largely as a grammatical concession, since early compilers already allowed it.

That's why East const exists. John Kalb popularized it, building on earlier work by Dan Saks, who wrote extensively about untangling C++ declarations. Nobody deliberately created two equivalent spellings. They fell out of the grammar because it was convenient and wouldn't break existing code.

const int* p;   // pointer to const int; change the pointer, not the value
int* const p;   // const pointer to int; change the value, not the pointer

The position of const relative to the asterisk matters: to the left of the asterisk, it becomes part of the specifier sequence and qualifies what the pointer points to.

To the right of the asterisk, it becomes part of the declarator and qualifies the pointer itself. This follows the original design principle that declarations should resemble the expressions that will later use the variable. That works nicely for int* p; for int (*f)(int), it's just a cruel joke. Adding const only makes an already complicated grammar harder to read.

And once again, there's no way to fix it. C++ inherited the parsing rules for const from C, and they're effectively set in stone. Changing them would break both C and four decades of code written in both languages. So const looks like a lock on a door, but it's really more like a "Please do not enter" sign with the text facing the door.

The zoo of integer types

How many integer types does C++ have? Around fifty, if you count the fixed-width aliases. And to make things more interesting, not all of them have a fixed size—the actual size depends on the compiler and the target platform.

bool                // yes, `bool` is also an integer (integral) type

char                // a SEPARATE type
signed char         // a SEPARATE type
unsigned char       // a SEPARATE type, there are three different types, not two

char8_t             // C++20
char16_t            // C++11
char32_t            // C++11
wchar_t

short
unsigned short
int
unsigned int
long
unsigned long
long long               // C++11
unsigned long long      // C++11

short, short int, signed short, signed short int       // 4 spellings → 1 type
int, signed, signed int                                // 3 spellings → 1 type
long, long int, signed long, signed long int           // 4 → 1

long long, long long int, signed long long, signed long long int  // 4 → 1
unsigned, unsigned int                                            // 2 → 1

int8_t   int16_t   int32_t   int64_t        // exact width (optional)
uint8_t  uint16_t  uint32_t  uint64_t       // 8 of them

int_least8_t  ... int_least64_t             // minimum width
uint_least8_t ... uint_least64_t            // 8 of them (required)

int_fast8_t   ... int_fast64_t              // fast width
uint_fast8_t  ... uint_fast64_t             // 8 of them

intmax_t  uintmax_t                          // the widest one
intptr_t  uintptr_t                          // under the pointer (optional)

std::size_t        // <cstddef>
std::ptrdiff_t     // <cstddef>
std::sig_atomic_t  // <csignal>
std::wint_t        // <cwchar>
std::streamsize, std::streamoff   // <ios>

int doesn't mean 32 bits. It means at least 16 bits, though it may well be 32. The only guarantee the standard gives is the chain short <= int <= long <= long long. On 64-bit Linux, long is 64 bits. On 64-bit Windows, long is still just 32 bits—all because of backward compatibility (remember that phrase). Use int64_t if you need a guaranteed 64-bit integer. I still don't understand why it carries the _t suffix—it isn't the 1990s anymore. Well, that's one more thing that can't be changed; more on that in the spoiler.

Character types deserve a special mention. There are seven of them, and sooner or later you'll find yourself wondering why a character can be signed or unsigned like an integer, how char differs from signed char and unsigned char (three distinct types, not two), what wchar_t actually is, how std::string differs from std::wstring, and why that difference can suddenly wreak havoc on your encoding. But that's a story for another day.

A history of the language

The type zoo is essentially a paleontological record of every machine C has ever run on. To understand why int isn't 32 bits, it helps to recall the hardware C grew up on.

C emerged in the early '70s, when computer architectures varied wildly. The PDP-11 used 16-bit words, for instance, while the Honeywell systems C was ported to early on used 36-bit words. Some modes even worked with 6- or 9-bit characters. Historically, a C byte was never guaranteed to be 8 bits. In the C standard, CHAR_BIT is the number of bits in the smallest addressable unit of memory, so a machine with CHAR_BIT == 9 is perfectly legal by the language rules.

CDC machines used 60-bit words; some architectures used two's complement, others one's complement. Given all that, Ritchie made the only sensible decision available: don't fix sizes at all. Instead, int simply meant "the machine's natural word type—the one the processor handles most efficiently—but at least 16 bits."

The language guaranteed only minimum ranges and the ordering short <= int <= long <= long long. Actual sizes were left to the target platform. Thanks to that decision, the same source code could compile efficiently on a 16-bit PDP-11, a 36-bit Honeywell, and a dozen other architectures. The fact that int had no fixed size was exactly what made C so portable.

Then 32-bit machines became the norm and int settled at 32 bits. When 64-bit systems arrived, int stayed put. By then the world was already full of code with sizeof(int) == 4 hard-coded into it. Widening int to 64 bits would have broken all of it, to say nothing of countless ABIs.

Microsoft even kept long at 32 bits. Why? A massive existing codebase, an enormous product ecosystem, and millions of users. Or, to put it simply: backward compatibility.

Untold lines of code and the Win32 API itself treated long as a four-byte type, used it interchangeably with int and DWORD, and serialized it to disk and across the network as four bytes. Fixing that was deemed too expensive. So long means different things on different platforms simply because in the late 1990s two ecosystems made different compatibility trade-offs.

int64_t and its _t suffix are essentially an admission that the language failed to make its fundamental integer types predictable. Decades later, a second family of fixed-width types was added in a separate header, <stdint.h>. The _t suffix isn't a relic of the 1990s; it's a relic of the 1970s. It comes from the Unix convention for typedef names, size_t, time_t, wchar_t where names ending in _t are reserved for implementation use. That lets the standard introduce new types without risking collisions with user-defined identifiers.

Non-standard standard library

If my goal were to confuse beginners as much as possible, I'd name things exactly the way the STL does. The most commonly used container is called vector, even though it's really a dynamic array. In the usual sense, a vector is a quantity with a direction. Even Alexander Stepanov, the creator of the STL, later admitted the name was a mistake.

If you need a hash table, you might reach for std::map. But that isn't a hash table—it's a balanced tree with logarithmic lookup. The actual hash table is std::unordered_map. And, spoiler alert, you're better off avoiding that one too, because it's slow. This isn't just a case of a lazy implementation; it's baked into the standard. The guarantees std::unordered_map has to provide leave libstdc++ and libc++ developers little choice but to make it slow.

std::map<std::string, int> ordered;
ordered["banana"] = 1;
ordered["apple"]  = 2;
ordered["cherry"] = 3;

for (auto& [k, v] : ordered)
    std::cout << k << ' ';  // ALWAYS: apple banana cherry, 
                            // in ascending order by key

std::unordered_map<std::string, int> hashed;
hashed["banana"] = 1;
hashed["apple"]  = 2;
hashed["cherry"] = 3;

for (auto& [k, v] : hashed)
    std::cout << k << ' ';  // arbitrary order; 
                            // it depends on the hash and buckets

std::unordered_map<std::string, int> m;
m.insert({"key", 1});
m.insert({"key", 2});  // It DIDN'T overwrite it but returned {iterator, false}
std::cout << m["key"];  // 1, not 2

m.insert_or_assign("key", 2);  // Starting with C++17, this will be overwritten
std::cout << m["key"];         // 2
m["key"] = 2;                  // or just for the sake of it

The standard mandates separate chaining with nodes, and unordered_map must guarantee that references and pointers to elements stay valid across insert and erase, the erased element aside. That means not even a rehash may invalidate a pointer to an existing element.

This is only possible if each element is allocated separately on the heap (std::pair<const Key, Value> plus a pointer to the next element) and each bucket is implemented as a linked list of such elements. In other words, what the standard describes isn't a "hash table in an array" but an "array of pointers to lists scattered across the heap." And that's not the only surprise lurking in the standard library. Here's another:

std::unordered_map<std::string, int> m;
if (m["key"] == 0) { }   // if the key did NOT exist, it was just added
                         // with a default value of 0.
                         // The "if the key exists" check created it.

The operator[] silently inserts the default value for a missing key, so check whether it exists using find/contains, not []. It's a small detail, but beginners stumble over this pitfall all the time.

Then there's empty() that sounds like it should clear the container, but it simply tells you whether the container is empty. You'd expect it to be called is_empty(), but it's not. Meanwhile, remove() doesn't actually remove anything; it simply moves matching elements to the end and returns an iterator. We still need to erase them using the erase-remove idiom. There are also std::stoi, std::stol, std::stoll, std::stof, std::stod, and std::stold, and devs just need to know what they are. Do you know?

Is it really standard?

To understand why the standard library sometimes seems designed to work against developers, it helps to remember that it was created by a mathematician. Alexander Stepanov spent decades developing the concept of generic programming, built on the idea that algorithms should depend on abstract type requirements rather than concrete data structures.

Before C++, he explored the approach in Scheme, then in Ada with David Musser. He eventually moved to C++, where he found that templates—originally designed for an entirely different purpose—were powerful enough to express all of his ideas. In 1993–1994 he brought the result of that work to the language's committee, and in a remarkably rare feat, he got nearly all of it into C++98 virtually unchanged.

That's where vector comes from. In Scheme's computing model, a vector was a one-dimensional contiguous array, so the name made perfect sense to Stepanov. People later realized array would have been a better fit, but by then vector had already made its way into the draft standard and countless codebases. Renaming it was no longer an option—the same story we keep running into throughout C++.

map has a similar history. The name accurately describes the abstraction: a mapping from keys to values. The trouble is that many developers come from Java or Python, where map or dict normally implies a hash table, so they instinctively expect the same behavior. When C++11 finally introduced a real hash table, the obvious name, hash_map, was already off the table—incompatible vendor-specific implementations from SGI, Microsoft, Dinkumware, and others had claimed it years earlier. Rather than break that entire ecosystem, the committee settled on the only unclaimed, if rather awkward, name available: unordered_map. The ugly name isn't so much a design mistake as another scar left by C++'s commitment to backward compatibility.

Don't forget about ...value

And to cover all the bases, there are lvalue, rvalue, glvalue, prvalue, and xvalue. Ring any bells?

In some cases std::move makes a copy, and what you actually need is std::move_if_noexcept. While we're on the subject of move semantics, std::move has been badly named from the very start. It doesn't move anything at all! All it does is cast its argument to an rvalue reference, making it eligible to bind to a move constructor or a move assignment operator. It really should have been called rvalue_cast. Then again, come to think of it, C++ probably doesn't need yet another cast.

Not every lvalue is an xvalue

C had just two value categories: lvalues and rvalues. C++11 introduced move semantics, and two were no longer enough. The language had to distinguish between "a named object you shouldn't touch" and "a temporary whose value you may take." Those are really two independent properties, and their combinations yield five value categories. That's where xvalue—short for eXpiring value, an object that has identity but whose value you may safely move from... comes in.

To mark an object as an xvalue, the language needed a dedicated operation. rvalue_cast would have been the obvious name, but the committee didn't want to introduce yet another cast. Instead, Howard Hinnant and the other designers picked a name that reflects intent rather than mechanics. So whenever you write std::move, read it as "I'm done with this object—you can take its value now."

The standard library also has a second std::move—one that actually moves elements. So, don't confuse the std::move that moves things with the std::move that doesn't. Someone once even showed me a 70-page PDF explaining when and how to use each one correctly. Too bad I don't remember its title.

That's without even getting into names of C++ idioms. Do you know what RAII is? It stands for Resource Acquisition Is Initialization, but the name points to the least important part of the idiom. RAII is really about the opposite: automatically releasing a resource in the destructor when an object goes out of scope. If anything, it should have been called CADR (Constructor Acquires, Destructor Releases) because that's what the idiom is actually about, not the fact that a constructor acquires a resource.

void process() {
    FileHandle file("data.txt"); // we opened it

    if (nothing_to_do())
        return;            // early exit, the file is closed automatically

    might_throw();         // an exception was thrown, he file is STILL closed
}                          // regular scope end, the destructor closed the file

Take CRTP as another example. Have you ever stopped to think about what the name actually means? CRTP stands for Curiously Recurring Template Pattern, and the name doesn't describe what the pattern does at all. Instead, it reflects the author's reaction: they kept running into this same template pattern in different codebases and found it curious enough to give it that name.

Modern C++

Have you heard that learning modern C++ is a must? However, a simple Google search for "what is modern C++" yields results from over two decades ago.

Effective Modern C++ by Scott Meyers (2014), with the subtitle "42 specific ways to improve your use of C++11 and C++14"

Modern C++ Design: Generic Programming and Design Patterns Applied

The Modern C++ Challenge

Modern C++: Efficient and Scalable Application Development

C++11 was the first release people called modern C++. It brought smart pointers, lambdas, and move semantics. Then came C++14, C++17, C++20, and C++23, each claiming to be the latest—and therefore the new "modern C++." The result is that even the bestselling Effective Modern C++ is dated and, in places, no longer effective. Meanwhile, much of the industry still lives in the C++17 era, because nobody is eager to rewrite millions of lines of production code just to make it "even more modern." The risk simply isn't worth it.

So developers have to be fluent in every major version of the standard—and trust me, they differ. The legacy code at your job targets one dialect, the new codebase another, the textbook a third, and the YouTube tutorial a fourth. And none of them count as "modern" anymore.

Errors that don't fit on the screen

When you finally get around to compiling something, you're greeted by the error messages. C++ can turn a single misplaced character into a thousand lines of nearly unreadable garbage, with the real cause buried somewhere in the middle. By the time you dig it out, your brain has already given up, because half the output is just the standard library's internals spilling across the screen.

Template instantiation errors read like an unreadable dialect of Chinese written entirely in angle brackets. They stretch so far horizontally that they won't fit on a 4K monitor. I'm not joking—I only came to appreciate ultrawide displays after staring at those errors. At some point I even turned off line wrapping, because it just made them harder to read. It's no wonder so many C++ developers end up with ultrawide monitors, glasses, and chronic neck pain.

Why errors are so wordy

A template isn't code. When you supply particular types, the compiler instantiates it by substituting those types throughout the definition. Only then does it check the resulting code for errors. It instantiates the entire template, replacing every occurrence with your type.

Now imagine the real problem lies deep inside an algorithm, because your type doesn't satisfy sort's requirements. By the time the compiler spots the error, it has already expanded ten layers of templates, and the only route back to the root cause is to dump the whole instantiation chain onto your screen. In a sense, this is duck typing at compile time. The template simply works if the operations inside it are valid. The downside is that duck typing brings the same style of error reporting: the problem doesn't surface where you made the mistake, but somewhere deep inside someone else's library, where the operation is actually used. The template has no idea what it's calling there—it isn't code yet; it only checks whether what it's handed fits.

For thirty years, templates had no way to express their requirements. You simply couldn't write "this template requires a comparable type," because under duck typing the requirements are always implicit.

The compiler had no way to say "you've violated requirement X," because no such requirement existed anywhere. The best it could do was drag you to line 4212 somewhere deep inside <algorithm> and point out that your type doesn't define operator<. And to convince you that's really where the trouble started, it had to dump the entire template instantiation stack on you.

Concepts... the feature that finally lets you name those requirements—trace their roots back to Alexander Stepanov's informal concepts from the late 1980s. They were originally slated for C++0x, but the committee pulled them from C++11 because the design was judged too complex. They finally landed in C++20, which is why we now write requires.

Zero-maybe abstractions

For the past twenty years, C++ has marketed itself as the language of zero-cost abstractions, but every abstraction has a cost. Take std::unique_ptr: it's slower than a raw pointer, because it has a non-trivial destructor, and under the Itanium ABI that means it can't be passed in a register. It can only go on the stack, whereas a raw pointer would land in a register.

And this isn't just about smart pointers. The same applies to any type with a non-trivial destructor: shared_ptr, string, vector—they all get passed by value through memory for the same reason. Move semantics aren't free either. The real cost comes from the destructor. Because C++ uses non-destructive moves, the moved-from object still has to run its destructor, and carefully written manual code can outperform the equivalent move-based implementation.

The regular expressions in the standard library are notorious as one of the worst implementations around. In some cases they run tens or even hundreds of times slower than the alternatives, and merely including <regex> can easily add about a second of compile time to every translation unit.

unordered_map isn't especially fast either: it's cache-unfriendly, and when performance really matters, developers often reach for flat_hash_map from Google's Abseil or F14 from Facebook's Folly instead. Spot the pattern? Plenty of C++ features could be substantially faster, but they probably never will be. Making them faster would break ABI compatibility—and that brings us to the main point.

Compatibility at a cost of everything else

All the complaints I've mentioned—from awkward names and slow containers to the static zoo and invisible copies—ultimately lead to the same conclusion. People think C++ puts performance above everything else, but in reality, its highest priority is backward compatibility. Performance comes second; developer ergonomics come second; the overall programming experience comes second. Everything comes second.

That commitment to compatibility is exactly what turned the language into the abomination it is today. You can't rename vector because it would break billions of code lines. You can't make unordered_map significantly faster because it would change the ABI. And you certainly can't introduce destructive move semantics—the opportunity passed more than a decade ago, and breaking existing code is simply off the table. Every wart in the language is a fossilized consequence of some long-forgotten design decision. You can't remove it because something already depends on it: someone's library, game engine, application, or entire build pipeline.

Ironically, the very thing people criticize C++ for is also the reason it powers such a large part of software over the world. Backward compatibility is both the language's greatest flaw and the key to its survival. Code you wrote twenty years ago will often still compile today—with a bit of tweaking and the occasional ritual sacrifice. Even an abandoned library from 2008 can link to a modern application. For industries like game development, where rewriting a codebase could cost dozens of person-years, this isn't a drawback—it's the load-bearing wall.

What about Rust, though?

People have been asking me in the comments to share my thoughts on Rust. Hopefully we can avoid turning this into another language war—it's simply a different language.

From a design standpoint, Rust is far better. It ships with a standard compiler, a standard build system, and a standard package manager, and there are no header files. The best compiler error messages I've ever seen, sensible defaults, no implicit conversions, proper UTF-8 support, sum types, and compile-time memory safety. Many of the problems C++ has yet to solve—and likely won't solve even in the next decade—have already been handled in Rust.

Being better designed doesn't automatically make it the right choice, though. Game development thrives on rapid iteration, creative chaos, and "let's see what happens if we try this." Rust doesn't really accommodate that style—and, to be fair, neither does modern C++, no matter how many features each new standard piles on. That's one reason game development has shifted more and more toward scripting languages, DSLs, and declarative programming.

At its core, Rust prioritizes correctness and discipline, and that creates a fundamental tension. A growing number of game projects have started in Rust only to move away from it for exactly that reason. Then there's the ecosystem. However you look at it, CUDA, game engines, tooling, and billions upon billions of lines of existing code all revolve around C++. And that isn't going to change anytime soon.

The worst/best programming language of all times?

C++ is a terrible language. It's verbose where it shouldn't be and silent where it shouldn't be. It comes with a zoo of types, misleading keywords, invisible copies, unreadable error messages, and a build system straight out of hell.

Writing good C++ takes an encyclopedic knowledge of the exceptions to the rules—and once you've memorized those, you still have to learn the exceptions to the exceptions. Yet C++ is very much alive, and it's likely to stay that way for decades. It has tremendous momentum, and it's one of the few languages that puts backward compatibility first, possibly at the expense of everything else. That single decision made C++ both unbearable and irreplaceable. Half the software world runs on it today, and it will keep running on it for a long time, whether I like it or not.

I write in this terrible language, romanticizing its complexity to prove to myself that I'm smart. And I'll keep writing in it, because in my field it's still the only language that delivers the performance I need. It's become a load-bearing wall. Replacing that wall in an occupied, constantly renovated building isn't as simple as redesigning a few rooms in some fashionable language. You'd have to tear the whole building down and rebuild it from scratch while living in a shed for the next couple of years.

So yes, C++ is a terrible language. Now fire up your terrible IDE and get back to coding in the worst programming language in the entire world!

Want to learn more?

The PVS-Studio team values the C++ community and doesn't miss an opportunity to talk more about how to improve workflows using static code analyzers. Here are some useful resources:

How catch-block selection works in exception handling
Silent foe or quiet ally: Brief guide to alignment in C++ (part 1, part 2, part 3)
How far does lookup see in C++?

Avoid adding new library to project: 10-year retrospective

Unicorn Developer — Wed, 02 Sep 2026 13:24:15 +0000

Everyone is trying to speed up software development by building their solutions using "bricks" like third-party components or libraries. However, we forget what problems they may trigger. Today, I'll try to explain why it's worth thinking twice before adding a new dependency to a project. The article is a remake that I've decided to write after realizing that my old recommendation is still relevant.

Ten years ago, I've said about it in the compilation of recommendations "The Ultimate Question of Programming, Refactoring, and Everything."

Many people criticized this point, which made me doubt whether I was right. After all, the world doesn't stand still: progress marches on. Developers put apps together like LEGO bricks, and plus, package managers have evolved. It's convenient for everyone, and everyone seems happy. So why am I bringing up my doubts?

I've not mentioned this topic again in later articles, including 60 terrible tips for a C++ developer (2023), but I've been watching how things have changed for several years, and I can say that my position has returned to what it was before: whenever possible, it's still better to avoid to add new libraries that spawn more dependencies.

And I think I was right, although to be honest, I've chosen not the best way to present this or not the best examples. Plus, the earlier arguments omit an important point that has come to the fore in the context of secure software development and certification. Actually, there is one, number 4, but it sounds too trivial. So let me try again.

First, I'll show an older, slightly reduced version of the text, and then I'll reinforce it with new arguments and thoughts. Overall, everything I've said still stands, and I ask that you think about what you've read before we get into another round of arguments in the comments :)

Chapter 41 from the 2016 collection of tips

Suppose you need to implement an X functionality in your project. Theorists of software development will say that you have to take the already existing library Y, and use it to implement the things you need. In fact, it is a classic approach in software development, reusing your own or others' previously created libraries (third-party libraries). And most programmers use this way.

However, those theorists in various articles and books, forget to mention what hell it will become to support several dozen third-party libraries in about 10 years.

I strongly recommend avoiding adding a new library to a project. Please don't get me wrong. I am not saying that you shouldn't use libraries at all, and write everything yourself. This would be insufficient, of course. But sometimes a new library is added to the project at the whim of some developer, intending to add a little cool small "feature" to the project. It's not hard to add a new library to the project, but then the whole team will have to carry the load of its support for many years.

Tracking the evolution of several large projects, I've seen quite a lot of problems caused by a large number of third-party libraries. I will probably enumerate only some of the issues, but this list should already provoke some thoughts:

Adding new libraries promptly increases the project size. In our era of fast Internet and large SSD drives, this is not a big problem, of course. But, it's rather unpleasant when the download time from the version control system turns into 10 minutes instead of 1.
Even if you use just 1% of the library capabilities, it is usually included in the project as a whole. As a result, if the libraries are used in the form of compiled modules (for example, DLL), the distribution size grows very fast. If you use the library as source code, then the compile time significantly increases.
Infrastructure connected with the compilation of the project becomes more complicated. Some libraries require additional components. A simple example: we need Python for building. As a result, in some time you'll need to have a lot of additional programs to build a project. So the probability that something will fail increases. It's hard to explain, you need to experience it. In big projects something fails all the time, and you have to put a lot of effort into making everything work and compile.
If you care about vulnerabilities, you must regularly update third-party libraries. It would be of interest to violators, to study the code libraries to search for vulnerabilities. Firstly, many libraries are open-source, and secondly, having found a weak point in one of the libraries, you can get a master exploit to many applications where the library is used.
One the libraries may suddenly change the license type. Firstly, you have to keep that in mind, and track the changes. Secondly, it's unclear what to do if that happens. For example, once, a widely used library softfloat moved to BSD from a personal agreement.
You will have troubles upgrading to a new version of the compiler. There will definitely be a few libraries that won't be ready to adapt for a new compiler, you'll have to wait, or make your own corrections in the library.
You will have problems when moving to a different compiler. For example, you are using Visual C++, and want to use Intel C++. There will surely be a couple of libraries where something is wrong.
You will have problems moving to a different platform. Not necessarily even a totally different platform. Let's say, you'll decide to port a Win32 application to Win64. You will have the same problems. Most likely, several libraries won't be ready for this, and you'll wonder what to do with them. It is especially unpleasant when the library is lying dormant somewhere, and is no longer developing.
Sooner or later, if you use lots of C libraries, where the types aren't stored in namespace, you'll start having name clashes. This causes compilation errors, or hidden errors. For example, a wrong enum constant can be used instead of the one you've intended to use.
If your project uses a lot of libraries, adding another one won't seem harmful. We can draw an analogy with the broken window theory. But consequently, the growth of the project turns into uncontrolled chaos.
And there could be a lot of other downsides in adding new libraries, which I'm probably not aware of. But in any case, additional libraries increase the complexity of project support. Some issues can occur in a fragment where they were least expected to.

Again, I should emphasize; I don't say that we should stop using third-party libraries at all. If we have to work with images in PNG format in the program, we'll take the LibPNG library, and not reinvent the wheel.

But even working with PNG we need to stop and think. Do we really need a library? What do we want to do with the images? If the task is just to save an image in *.png file, you can get by with system functions. For example, if you have a Windows application, you could use WIC. And if you're already using an MFC library, there is no need to make the code more sophisticated, because there's a Cimage class (see the discussion on Stack Overflow). Minus one library—great!

Recommendation

Keep resisting the temptation to add new libraries to your project. Add it only when you're sure that libraries are really indispensable.

What to do? Here are some possible maneuvers:

Check your system's API or one of the libraries you're already using whether it has this functionality.
Implement the functionality by yourself if it's not so huge instead of using only a very small part of the library's functionality. The argument that "I add the whole library and maybe it'll be handy someday in the future" isn't worth the trouble. Usually it doesn't happen. Yes, programmers are too focused on versatility, which often isn't needed.
Choose the simplest library that meets your requirements and helps you solve the task. As mentioned above, don't choose a more powerful library "just in case."
Just wait a moment and think over before adding the library. Have some tea, take a break, and discuss the task with your colleagues. You may find that you don't need a third-party library after all and can solve the problem another way.

P.S. Many people won't like what is said here. For example, I recommend using WinAPI rather than a non-portable universal library. It kind of locks the project into a single operating system and complicates the further program migration—and I can't agree with this point. This idea to migrate the program to another OS is just sitting in the developer's head, but in reality, management may never set such a goal at all, or the project will fail due to excessive complexity and versatility, even before it gains popularity and the need for porting arises. Also, don't forget item (8) on the list of issues provided above.

The end of the old post, but not the end of the story

Everything said in the original is still true today, although the emphasis has shifted. Today, we need to focus on controlling an overly gigantic codebase when establishing secure development processes. Now it is coming to the forefront. Point number 4 has become truly urgent.

Adding libraries in your projects triggers the creation of transitive dependencies. This means that the library uses other libraries, which in turn use other libraries, and so on. Now the required 10 libraries for your projects, in reality, turn into 100s being used. In some languages, such as C++, this is not very noticeable, whereas when developing in JavaScript, Java, or Python, huge chains of dependencies quickly emerge.

If a vulnerability is detected in one of these libraries, it means your application is also potentially vulnerable. It doesn't matter to the user whether your app is vulnerable because of your own code or third-party code.

Of course, the vulnerability in a particular library doesn't automatically mean that your application is vulnerable as well. Dangerous functions may simply never be called, or work with data that won't cause any problems. This means that the vulnerability isn't the primary attack target.

However, that doesn't make it much easier. After all, we need to be sure that the vulnerability can't be exploited. And in reality, it can be really hard work.

So, if you think about your project's reputation, it's worth tracking all new vulnerabilities in all components that are used directly or indirectly, for example, using Software Composition Analysis (SCA) tools for this purpose.

If you have composition analysis tools, what's the problem with having a large number of dependencies? The more there are, the greater the chance that someone will find a new vulnerability and exploit it.

That's not all. Vulnerabilities may be caused not only by a random bug, but can also be the intentional act. For example, supply chain attacks become more well-known problem: attackers use various methods to inject undocumented features into various open-source libraries. For example, they contribute some changes and enhancements for a while, build up a positive reputation, and then sneak a backdoor into the code. Transitive dependencies open the door to exploit a large number of applications at once. So, the more third-party libraries you use, the higher the risk of supply chain attacks.

Another option of such an attack has emerged related to AI-generated code (GenAI). AI can hallucinate in the names of the required packages. It's clear that hallucinations follow certain patterns, and malicious actors will not miss the opportunity and use it: they create and publish compromised packages with names that GenAI is most likely to hallucinate. It sounds far-fetched, but it works, and such attacks have already been used. They came to be known as slopsquatting.

The next topic is static analysis. From a security standpoint, you should review your own code plus all third-party code. Few people do this, since most people tend to focus only on viewing their own code. But anyone who stops to think about it is faced with a huge amount of work.

However, if you want to conduct certification testing on your project, it makes no difference whether you wrote the code yourself or obtained it from an external source. Do you use third-party code? It's yours now. Take responsibility for it. That makes sense: it doesn't matter who wrote the code that makes the app vulnerable.

In practice, it may be impractical for a single company to perform a static analysis of all borrowed code. This has given rise to trusted repository projects and consortia of companies for the conjoint analysis of borrowed components. One approach is to analyze the initial modules that make up the attack surface. Here again, the problem of defining this surface arises. I won't go into detail here.

Conclusion

Of course, it won't impact on our habit to eagerly add third-party components into the project. I'm not calling to change that; it'd be counterproductive. However, I still want you to be aware of the potential problems you might encounter.

I think you can try a little bit enhance your code review process by controlling (or discussing) all libraries that are added. Let the developer explain why they really need yet another library. Perhaps, if they have known this during the development phase, they would have chosen a different approach to solving the problem or used the functionality of another library that was already included in the project. In short, try to avoid adding new libraries to the project. Maybe it'll actually work out for you someday :) And you will thank me later.

Ideally, it would be a good idea to audit your project from time to time to check whether all project-related libraries are being used. I've seen cases where, while porting a large C++ application from Win32 to Win64, it turned out that about 10 libraries weren't being used at all. At the same time, resources had been spent for many years on maintaining them within the project. Conducting such an audit may not be easy, but you might be able to pull it off.

We checked the source code of VS Code

Unicorn Developer — Tue, 01 Sep 2026 06:33:05 +0000

No more tiptoeing, we can finally say it out loud: we've released a static code analyzer for JavaScript and TypeScript. So naturally, it's time to send it out into the wild and see what it catches in the source code of Visual Studio Code, an open-source project most developers know all too well. Here's what turned up.

Before we start

This section is for anyone who isn't familiar with our article format, so you know what to expect.

At PVS-Studio, we build a static code analysis tool. Basically, a static analyzer is a program that looks for logical errors in the source code of other programs. For this kind of article, we pick a popular open-source project, run our analyzer on it, and share what we find with our readers, as well as with the project's developers, by filing issues and pull requests.

With the current release, we're adding a new analyzer for JavaScript and TypeScript. Right now it runs on a basic set of diagnostic rules, but it's already capable of catching real errors and flagging suspicious code.

To show it tackling something real, we picked a project pretty much everyone's heard of, Visual Studio Code. It combines JavaScript and TypeScript code, and the codebase is quite large, so we were curious to see what our newcomer would find in it.

We ran the analysis on release version 1.128.0, the latest version at the time of writing, at commit fc3def677. We cloned the repo, ran the analysis, and once it finished, picked out the most interesting results. Now for the results.

Accessing an array in a strange way

In this section, and in the ones that follow, you'll see a code snippet containing either an outright error or code that looks off and is worth a second look, followed by the PVS-Studio warning and a link to the source in the repository. Right after that, we'll explore what's wrong with the actual code.

The first error for today is a rather extravagant way to access an array:

....
const diffs = changes.map(splice => {
    return [splice[0], splice[1], splice[2].map(....)] 
             as [number, number, CellViewModel[]];
});
....
for (let i = 0; i < diffs.length; i++) {
  const diff = diffs[0];                 // <=
  if (diff[0] + diff[1] <= primarySelectionIndex) {
    delta += diff[2].length - diff[1];
    continue;
  }
  if (diff[0] > primarySelectionIndex) {
    endSelectionHandles = [primaryHandle];
    break;
  }
  if (diff[0] + diff[1] > primarySelectionIndex) {
    endSelectionHandles = [this._viewCells[diff[0] + delta].handle];
    break;
  }
}
....

The PVS-Studio warning: V7016 Suspicious access to an element of the 'diffs' object by a constant index inside a loop. notebookViewModelImpl.ts 252

Here, we have an array being built, followed by an attempt to loop through it. Why an attempt? The i index is never actually used within the array, instead, the line marked with the comment // <= always pulls the element at index 0. As a result, on every single iteration, checking diff means dealing with the first element of the diffs collection.

Judging by the snippet itself, that wasn't the intent. The plan was clearly to check each i-th element, but a typo is a typo.

This is a recurring pattern across other languages too. Our Java analyzer, for instance, has caught similar issues before.

So we're moving on.

Checking the wrong thing

....
let lastValueAtPosition: boolean | undefined = undefined;
let lastValueOnLine: boolean | undefined = undefined;
timeouts.add(autorun(reader => {
  const newValueAtPosition = 
          s.source.isPresentAtPosition(args.position, reader);
  const newValueOnLine = 
          s.source.isPresentOnLine(args.position.lineNumber, reader);
  if (   lastValueAtPosition !== undefined 
      && lastValueAtPosition !== undefined) {  // <=
    if (!lastValueAtPosition && newValueAtPosition) {
      trigger(s.property, s.source, 'positional');
    }
    if (!lastValueOnLine && newValueOnLine) {
      trigger(s.property, s.source, 'line');
    }
  }
  lastValueAtPosition = newValueAtPosition;
  lastValueOnLine = newValueOnLine;
}));
....

The PVS-Studio warning: V7001 The operands of the '&&' operator in the 'lastValueAtPosition !== undefined && lastValueAtPosition !== undefined' expression are equivalent. editorTextPropertySignalsContribution.ts 152

The code has two variables, lastValueAtPosition and lastValueOnLine, both typed as boolean or undefined. And in the arrow function they're passed into, the intent was to first check that neither one is undefined, and only then treat them as boolean values.

There's a typo in the condition the analyzer flagged: the binary expression && uses identical operands. As a result, lastValueOnLine never gets checked against undefined, meaning the second nested if statement can behave incorrectly.

Shady self-assignment

The assignment operator comes with its share of sneaky typos, here's the first one.

The first snippet:

swapChildren(from: number, to: number): void {
  from = validateIndex(from, this.children.length);
  to = validateIndex(to, this.children.length);
  if (from === to) {
    return;
  }
  this.splitview.swapViews(from, to);
  // swap boundary sashes
  [this.children[from].boundarySashes, 
   this.children[to].boundarySashes] = 
  [this.children[from].boundarySashes, 
   this.children[to].boundarySashes]; // <=
  // swap children
  [this.children[from], this.children[to]] = 
    [this.children[to], this.children[from]];
  this.onDidChildrenChange();
}

The PVS-Studio warning: V7005 The expression '[this.children[from].boundarySashes, this.children[to].boundarySashes]' is assigned to itself. gridview.ts 575

In this code, the goal was to use destructuring to swap the values of this.children[from].boundarySashes and this.children[to].boundarySashes. Destructuring is a handy way to do this kind of swap without introducing a third variable. But for it to actually work, the values on the right side of the assignment needed to be in the opposite order. As it stands, the // swap boundary sashes comment doesn't match what the code actually does.

By the way, a similar swap happens further down, with different values, and that one doesn't have this typo.

The second snippet:

export class LanguageModelTextPart implements vscode.LanguageModelTextPart2 {
  value: string;
  audience: vscode.LanguageModelPartAudience[] | undefined;  

  constructor(value: string, audience?: vscode.LanguageModelPartAudience[]) {
    this.value = value;
    audience = audience;  // <=
  } 

  toJSON() {
    return {
      $mid: MarshalledId.LanguageModelTextPart,
      value: this.value,
      audience: this.audience,
    };
  }
}

The PVS-Studio warning: V7005 The variable 'audience' is assigned to itself. extHostTypes.ts 4033

Another assignment typo, but in a different context this time. There's a constructor parameter named audience and a class field also named audience. When assigning a value to the audience field, the code forgot the this keyword. As a result, the audience field never gets initialized.

The third snippet:

export class ServerInstalledExtensionsView extends ExtensionsListView {
  override async show(query: string): Promise<IPagedModel<IExtension>> {
    query = query ? query : '@installed';
    if (....) {
      query = query += ' @installed';  // <=
    }
    return super.show(query.trim());
  }
}

The PVS-Studio warning: V7005 The variable 'query' is assigned to itself. extensionsViews.ts 1310

This one's similar, but it's hardly an error, more of a typo or an odd use of the += operator. The += operator already assigns the new value to query on its own, so the query = .... part in front of it is redundant.

In this particular spot, it's very unlikely to cause any real trouble. But the same kind of typo, if it landed on a plain = assignment meant for a different variable, could actually cause problems. And beyond that, a new developer reading this code would have to stop and figure out whether there's a real bug here or whether the redundant assignment is just harmless. That's reason enough not to leave code like this as is.

There're similar warnings in the project:

V7005 The variable 'filePath' is assigned to itself. fileLoading.ts 31
V7005 The expression 'tunnelProperties.privacy' is assigned to itself. tunnelModel.ts 773
V7005 The variable 'value' is assigned to itself. task.ts 75

HTTPS or HTTPS?

private onFocusChanged(event: ITableEvent<ITunnelItem>) {
  if (event.indexes.length > 0 && event.elements.length > 0) {
    this.lastFocus = [...event.indexes];
  }
  const elements = event.elements;
  const item = elements && elements.length ? elements[0] : undefined;
  if (item) {
    this.tunnelViewSelectionContext.set(
      makeAddress(item.remoteHost, item.remotePort));
    this.tunnelTypeContext.set(item.tunnelType);
    this.tunnelCloseableContext.set(!!item.closeable);
    this.tunnelPrivacyContext.set(item.privacy.id);
    this.tunnelProtocolContext.set(item.protocol === TunnelProtocol.Https 
                                                  ? TunnelProtocol.Https 
                                                  : TunnelProtocol.Https); // <=
    ....
  }
}

The PVS-Studio warning: V7012 [CWE-1041] The conditional expression 'item.protocol === TunnelProtocol.Https ? TunnelProtocol.Https : TunnelProtocol.Https' always returns the same value. tunnelView.ts 997

Here, the analyzer flags that both branches of the ternary return the same value, TunnelProtocol.Https. We checked TunnelProtocol, and sure enough, the else branch should be returning TunnelProtocol.Http instead.

Interestingly, we'd already flagged this one ourselves, and while double-checking it before writing this article, we noticed that a few days after our check, one of VS Code's users had spotted the same bug independently. Here's a link to their pull request. This is a good example of static analysis catching errors before they make it into the master branch.

Another warning for V7012 also flagged the following snippet:

....
if (this.selection.endColumn <= this.targetPosition.column) {
  // The target position is after the selection's end position
  this.targetSelection = new Selection(
    this.targetPosition.lineNumber - this.selection.endLineNumber 
      + this.selection.startLineNumber,
    this.selection.startLineNumber === this.selection.endLineNumber 
      ? this.targetPosition.column - this.selection.endColumn 
          + this.selection.startColumn                                
      : this.targetPosition.column - this.selection.endColumn 
        + this.selection.startColumn,                        // <=
    this.targetPosition.lineNumber,
    this.selection.startLineNumber === this.selection.endLineNumber ?
      this.targetPosition.column :
      this.selection.endColumn
  );
}
....

The PVS-Studio warning: V7012 [CWE-1041] The conditional expression always returns the same value. dragAndDropCommand.ts 86

Here too, the analyzer points out identical expressions in the branches of the ternary operator, but this one isn't as clear-cut as the last. It looks like the then and else branches probably aren't meant to be identical, but what one of them should actually contain is anyone's guess. This is a case where the fix should come from someone who fully understands what this code is meant to do.

Unreachable condition

....
const lineCount = model.getLineCount();
const endLine = lineNumber === lineCount;
const prevLineEmptyOrIndented = 
        lineNumber > 1 && isLineEmptyOrIndented(lineNumber - 1);
const nextLineEmptyOrIndented = 
        !endLine && isLineEmptyOrIndented(lineNumber + 1);
const currLineEmptyOrIndented = isLineEmptyOrIndented(lineNumber);
const notEmpty = !nextLineEmptyOrIndented && !prevLineEmptyOrIndented;
// check above and below. if both are blocked, display lightbulb in the gutter.
if (!nextLineEmptyOrIndented && !prevLineEmptyOrIndented && !hasDecoration) {
  this._gutterState.set(....);
  this.renderGutterLightbub();
  return this.hide();
} else if (prevLineEmptyOrIndented || endLine || 
          (prevLineEmptyOrIndented && !currLineEmptyOrIndented)) {    // <=
    effectiveLineNumber -= 1;
}
....

The PVS-Studio warning: V7018 The expression 'prevLineEmptyOrIndented || (prevLineEmptyOrIndented && ...)' is redundant and always evaluates to 'prevLineEmptyOrIndented'. lightBulbWidget.ts 373

In this snippet, the analyzer caught an odd pattern in the condition. The warning itself points out that if you set aside the second subcondition, || endLine, what's left is prevLineEmptyOrIndented || (prevLineEmptyOrIndented && ...). Once the condition is reduced to that form, it's clear that we'll either never reach the second part, or it won't evaluate to true anyway.

Forgotten return

....
if (focusedRepository) {
  ....
  // Resource Groups
  const resourceGroups: string[] = [];
  for (const resourceGroup of focusedRepository.provider.groups) {
    resourceGroups.push(
      `${resourceGroup.label} (${resourceGroup.resources.length} resource(s))`);
  }

  focusedRepository.provider.groups.map(g => g.label).join(', '); // <=
  content.push(
            localize(
              'state-msg6', 
              "Resource groups: {0}", resourceGroups.join(', ')));
}
....

The PVS-Studio warning: V7010 [CWE-252] The return value of function 'join' is required to be utilized. scmAccessibilityHelp.ts 108

The problem is that the result of calling join is never stored anywhere. Because of that, the line calling it is doing literally nothing.

Bugs like this usually come from one of two things: either a developer just forgets to write the assignment, or there's confusion about how a method actually works, whether it mutates the object in place or returns a new value. Since the code above shows the correct usage of join, we're leaning toward the first explanation.

Identical operands

The first snippet:

....
if (gapOriginalLength > 0) {
  const gapStartOffset = 
    nesOffset + lastChange.originalStart + lastChange.originalLength;
  const gapStartPos = textModel.getPositionAt(gapStartOffset);
  const wordRange = textModel.getWordAtPosition(gapStartPos);
  if (wordRange) {
    const wordStartOffset = 
      textModel.getOffsetAt(
        new Position(gapStartPos.lineNumber, wordRange.startColumn));
    const wordEndOffset = 
      textModel.getOffsetAt(
        new Position(gapStartPos.lineNumber, wordRange.endColumn));
    const gapEndOffset = gapStartOffset + gapOriginalLength;
    if (wordStartOffset <= gapStartOffset && gapEndOffset <= wordEndOffset 
        && wordStartOffset <= gapEndOffset 
        && gapEndOffset <= wordEndOffset) {  // <=
      lastChange.originalLength = 
          (change.originalStart + change.originalLength) 
            - lastChange.originalStart;
      lastChange.modifiedLength = 
          (change.modifiedStart + change.modifiedLength) 
            - lastChange.modifiedStart;
      continue;
    }
  }
}
....

The PVS-Studio warning: V7001 The operands of the '&&' operator are equivalent. renameSymbolProcessor.ts 141

Here, the analyzer is pointing at this condition:

   wordStartOffset <= gapStartOffset && gapEndOffset <= wordEndOffset
&& wordStartOffset <= gapEndOffset && gapEndOffset <= wordEndOffset

Since the variable names in this condition are so similar to each other, the issue isn't obvious at a glance. But look closely and gapEndOffset <= wordEndOffset is checked twice in that chain.

That repetition is what makes this potentially risky, since this could be more than just a harmless extra condition. When code has a run of similar-looking lines, variable names, or object names, it's easy to accidentally reference the wrong one. That's exactly the kind of mistake a quick read-through can miss, since the operands of && all look alike here. Hopefully it really is just an unnecessary condition, nothing more.

The second snippet:

....
if (   response.status === 401 
    && text.includes('authorize_url') 
    && jsonData?.authorize_url
) {
  return {
    type: FetchResponseKind.Failed,
    modelRequestId: modelRequestIdObj,
    failKind: ChatFailKind.AgentUnauthorized,
    reason: response.statusText || response.statusText, // <=
    data: jsonData
  };
}
....

The PVS-Studio warning: V7001 The operands of the '||' operator in the 'response.statusText || response.statusText' expression are equivalent. chatMLFetcher.ts 1641

Another one like the last, and it looks like a typo too. Elsewhere in the code, reason is set as follows:

reason: jsonData.message || 'Invalid previous response ID'

Or like this:

reason: jsonData?.message || `token expired or invalid: ${response.status}`

The third snippet:

....
// Notebooks are not supported yet.
if (URI.isUri(variableRef.value)) {
  if (await this.ignoreService.isCopilotIgnored(variableRef.value)) {
    return;
  }
  if (
    variableRef.value.scheme === Schemas.vscodeNotebookCellOutput 
    || variableRef.value.scheme === Schemas.vscodeNotebookCellOutput
  ) {
    return;
  }
  ....
  validReferences.push(variableRef);
  fileFolderReferences.push(variableRef);
  return;
}
....

The PVS-Studio warning: V7001 The operands of the '||' operator are equivalent. copilotcliPromptResolver.ts 136

The variableRef.value.scheme field is compared against the same constant from Schemas. Here are the other candidates in Schemas that this comparison could have been checking against instead:

export const vscodeNotebookCell = 'vscode-notebook-cell';
export const vscodeNotebookCellMetadata = 'vscode-notebook-cell-metadata';
export const vscodeNotebookCellMetadataDiff = 
                  'vscode-notebook-cell-metadata-diff';
export const vscodeNotebookCellOutput = 'vscode-notebook-cell-output';
export const vscodeNotebookCellOutputDiff = 'vscode-notebook-cell-output-diff';
export const vscodeNotebookMetadata = 'vscode-notebook-metadata';
export const vscodeInteractiveInput = 'vscode-interactive-input';

The fourth snippet:

static isEqual(a: Diagnostic | undefined, b: Diagnostic | undefined): boolean {
  if (a === b) {
    return true;
  }
  if (!a || !b) {
    return false;
  }
  return a.message === b.message
    && a.severity === b.severity
    && a.code === b.code
    && a.severity === b.severity
    && a.source === b.source
    && a.range.isEqual(b.range)
    && equals(a.tags, b.tags)
    && equals(a.relatedInformation, 
              b.relatedInformation, 
              DiagnosticRelatedInformation.isEqual);
}

The PVS-Studio warning: V7001 The operands of the '&&' operator are equivalent. diagnostic.ts 99

The expression a.severity === b.severity shows up twice here. It looks odd, but every field of Diagnostic is already checked, so the developers just tacked on a redundant condition.

The exact same thing happens in this next comparison:

V7001 The operands of the '&&' operator are equivalent. keyboardLayoutService.ts 431

To wrap up, a bit more on this group of V7001 warnings:

Every example here comes down to the same question: is the repeated operand just redundant, or is it a real typo? Figuring that out usually eats up more time than it should, which is exactly why this kind of thing shouldn't slip into the code in the first place.

But mistakes like this are genuinely easy to miss during a code review. Unlike a person, a static analyzer never loses focus, which makes it invaluable when working through large amounts of repetitive code. Static analysis pays off in plenty of other situations too, but these examples make its benefits especially clear.

Misleading formatting

if (isResourceMergeEditorInput(editor)) {
    ....
} if (isResourceDiffEditorInput(editor)) {
    ....
} else if (isResourceEditorInput(editor)) {
    resources.add(editor.resource);
}

The PVS-Studio warning: V7030 [CWE-670] Suspicious code formatting. The 'else' keyword is probably missing. editorService.ts 739

Above is a shortened snippet, with the original formatting kept intact. Judging by the formatting and the pattern of checks, that second block should be an else if, just like the last one.

We looked closely at this snippet and didn't find anything worse than an extra check running when the first condition is met. But code like this:

is misleading;
runs an unnecessary check;
and if the final statement were a plain else instead of else if, it would run even after the first if had already executed.

That last point is the scary one, and it's a good thing this particular block uses else if. Just like before, this is the kind of thing a human reviewer can easily miss, but a static analyzer catches it without any trouble.

When static analysis prepares the ground for refactoring

Besides catching potential errors, as we covered above, a static analyzer can also be a real asset for refactoring. A high number of warnings in one area can be a sign that certain code could, and sometimes should, be simplified. That's what we'll look at next.

Simplify switch-case

function walkChildren(
    node: TSESTree.Node, 
    visit: (child: TSESTree.Node) => void
) {
  switch (node.type) {
    ....
    case 'ForInStatement':  // <=
        visit(node.left);
        visit(node.right);
        visit(node.body);
        break;
    case 'ForOfStatement':
        visit(node.left);
        visit(node.right);
        visit(node.body);
        break;
    case 'WhileStatement':
    case 'DoWhileStatement':
        visit(node.test);
        visit(node.body);
        break;
    ....
    default:
        break;
  }
}

The PVS-Studio warning: V7008 [CWE-691] Two or more case branches perform the same actions. code-no-accessor-after-await.ts 365

In this snippet, the case branches for ForInStatement and ForOfStatement do exactly the same thing. Given that WhileStatement and DoWhileStatement are already stacked just below, there's a good argument for doing the same here.

Some occasional self-subtraction

....
while (byteCount > 0) {
  const chunk = this._chunks[chunkIndex];
  if (chunk.byteLength > byteCount) {
    // this chunk will survive
    const chunkPart = chunk.slice(0, byteCount);
    result.set(chunkPart, resultOffset);
    resultOffset += byteCount;
    if (advance) {
      this._chunks[chunkIndex] = chunk.slice(byteCount);
      this._totalLength -= byteCount;
    }

    byteCount -= byteCount;  // <=
  } else {
    // this chunk will be entirely read
    ....
    byteCount -= chunk.byteLength;
  }
}
return result;
....

The PVS-Studio warning: V7014 The identical expression 'byteCount' to the left and to the right of a compound assignment. ipc.net.ts 243

This one made it into the refactoring section because it's very likely the developers actually meant to zero out byteCount here, to guarantee the loop would exit. Figuring that out took a moment, though, since the else branch just below makes it look like this could just as easily be a typo.

To make the intent clear, it's better to just set the value to 0 directly.

Simplify the condition:

set(element: TextEditElement) {
  this._localDisposables.clear();

  this._localDisposables.add(
    dom.addDisposableListener(this._checkbox, 'change', e => {
    element.setChecked(this._checkbox.checked);
    e.preventDefault();
  }));
  if (element.parent.isChecked()) {
    this._checkbox.checked = element.isChecked();
    this._checkbox.disabled = element.isDisabled();
  } else {
    this._checkbox.checked = element.isChecked();
    this._checkbox.disabled = element.isDisabled();
  }
  ....
}

The PVS-Studio warning: V7004 [CWE-691] The 'then' statement is equivalent to the 'else' statement. bulkEditTree.ts 595

As things stand, the else block in this snippet doesn't do anything meaningful.

But like all the other snippets here, this one is best left for VS Code's active contributors and maintainers to look into.

Before we go

And that brings us to the end of the article. We've walked you through what we think are the most interesting things the PVS-Studio analyzer found in the VS Code source code. That's a solid outcome for us: even though the JavaScript and TypeScript analyzer is only just launching as an MVP, it's already catching suspicious code and real errors, even if a lot of them are simple typos for now. Down the line, once we add data-flow analysis and other features, the analyzer will get better at spotting more complex issues too.

By the way, some of our diagnostic rules started out as ideas our users and blog readers suggested to us. So if you've got thoughts on what kinds of errors our analyzer should be catching in JavaScript and TypeScript code, we'd love to hear them, some might even become real rules.

It was a lot of fun writing this article for you, and we hope you enjoyed reading it. Good luck out there, and see you next time.

P.S. You can try our analyzer on your own project here.