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.
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.
>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.
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.
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.
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.)
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)
Generally, things that are not open source are rarely not well written, since there are less programmers who will read your code, and all questions on the code can be done internally, so developers only write code so it works.
Open source generally leads to better quality code, since it's the best way to attract other developers to contribute to it.
So I'm rarely interested by any accomplished project that opens its code.
For example, if microsoft opened its OS, I doubt developers would really try to do things with it. The windows kernel would obviously be high quality code, but a lot of the rest is probably short lived garbage.
I disagree with this line of reasoning. I have seen good/bad examples on either side. I think it actually comes down to someone on the developer team having a high set of standards that they push everyone to subscribe to.
All the open source projects I have personally seen were ones meant to live a long time. When there were code issues, there were always awkward discussions on github about “there should be unit tests here” or “this code makes no sense,” and weeks later the developer announcing a cleanup or some sort. Anecdotal but public scrutiny and pressure is a real thing.
Just as an example, this is why Bitwarden started getting some automated testing - lots of propelled bumping github issues about it in order to get it more visibility
It's only tangentially related to code quality but I do think open/free source is the only way to write sustainable software if your aim is to change the world rather than ones bank account (so to speak).
There's terrible code all over the place, although it is definitely true that no one's going to clean up - even source available - proprietary code out of kindness of their heart.
Openness aside, working under constant pressure with crazy deadlines also paves the way for ugly/barely tested/hard to maintain code. Game studios often have extremely strict deadlines, but I've experienced this pressure also when working in government software; this code looks like examples from Dr Dobb's compared to the pile of crap we sometimes could barely stick together in the old days.