[ratww]

I completely agree.

Another similar issue that I see a lot in both Java and C++ codebases is "premature wrapping" of foreign APIs. Basically when building a program that has to consume a certain API that is somewhat incompatible, every single concept of this API is wrapped in a separate class before any planning, to the point each one-line procedure call turns into a 20 line class.

Of course, after the wrapper is written, the program still needs higher lever abstractions that use those wrappers. But since zero planning went into the design, now you need exactly the same call order as before, however instead of an ugly (but simple) procedure call, you have a class wrapping it, and to understand a simple workflow you have to go trough at least two layers of classes.

[adverbly]

Ugh same. Very common that I get slightly irritated by folks who blindly wrap something with no real reason other than "somebody else wrapped something similar so I'll wrap this for consistancy". Too many juniors thinking that they need more files/PR due to impostor syndrome...

[ratww]

Having worked in games, my pet peeve is the cottage-industry of amateur game engines and Youtube game-engine series that are pretty much just that: wrappers around OpenGL, SDL, Entt, Imgui and a multitude of other libraries.

Most of those never really produce a game, since the authors know how to wrap the libraries, but the engines don't have enough substance to help making a real game.

A notable exception however is Casey Muratori (of Handmade Hero), who actually skipped the wrapping and went for a more direct code. Interestingly he has a nice inversion of control architecture.