[Roritharr]

Interesting sentiment, I sometimes wonder if a "messy" codebase can have advantages for performance.

Many very highly performance tuned applications I saw in the wild would fall into the category of "horrible codebase" when looked at through that lens.

[nocturnial]

It falls more in the category of having a lot bugs which could've been caught if they used static code analysis, code review, etc...

I understand that you might think that messy could mean it's fine tuned for performance. In this case, I highly doubt it and think it's more reasonable to think it's messy because they had deadlines.

The messy part isn't about performance optimizations. It's more about things that got crammed in there and only works for a very specific subset of parameters. And even then you can't be sure it'll work...

I don't blame the programmers, it feels they had deadlines to uphold from managment.

[noarchy]

>I don't blame the programmers, it feels they had deadlines to uphold from managment.

This is my own experience. The teams that spent the most time on standards usually had the least pressure, in terms of things like deadlines. Once the focus of the team shifts to having to ship things, there is less time to worry about having 100% code coverage (to pull out an arbitrary number), and so forth. Code review can slip into flagging only things that really matter, and leaving nitpicks for another day.

[gentleman11]

What sorts of static code analysis tools do people here use in their game projects? I know carmack is a big fan of them

[nocturnial]

Here are the results for cry engine specifically:

https://www.viva64.com/en/b/0417/

https://www.viva64.com/en/b/0495/

https://www.viva64.com/en/b/0574/

I'm not endorsing pvs studio nor am I saying it's bad. Try out some tools and see what works best for you.

[projektfu]

It's funny because many of these are the exact possible errors you expect when someone is swimming in a large code block doing lots of copy and paste. Large blocks of code are very hard to test thoroughly, so I imagine the testing was mostly looking to see if things look right followed by play-testing.

[gameswithgo]

I have used the Rust compiler, which will catch all memory errors, data races, and null pointer exceptions and buffer overflows at compile time as a matter if course. then you can add cargo fuzz if you like.

[wwright]

Let’s assume that when code is first written, the cleanliness and performance is somewhat random within a broad range.

If we want the code to be clean or performant, we will likely have to spend time iterating on and pruning the code. Let’s assume that improving performance and improving cleanliness are at best orthogonal, at worst opposing.

The project has a limited amount of time, particularly for games, which often have a relatively low roof for how much maintenance the code will need.

The project has a budget on time to spend between cleanliness and maintenance. Games need high performance and relatively little maintenance, so they are more likely to spend their budget on much more performance than cleanliness.

(Game engines meant for heavy reuse such as Frostbite and Unreal Engine would likely have a much more even split, and similar for games which are likely to receive recurring and invasive updates. I would expect Fortnite’s code to be fairly clean as games go, for example.)

[mhh__]

I don't think it's necessary. With modern C++ it's possible to encapsulate high performance code.

The issue with games in particular is probably partly due to the performance optimizations being directed at a moving target (it's not just your supercomputer nodes, it's every computer CPU). C++ doesn't really help you much in that regard (or at least better know but certainly not 10 years ago)