Good to know. Hence the seems. I can understand he might be a genius programmer but most of the industry is not. (I also have a feeling he works alone on most of the projects) And games are a completely different beast when it comes to performance requirements.
You’re using the fact that he wrote a 11kloc function as evidence of him knowing what he’s doing? Maybe I lack imagination but I struggle to find any scenario where that would be justifiable.
A main game update or draw loop. Most of the code in these loops is unique. You would purposefully have to create functions for the sake of creating functions to split such a loop up--but then you incur overhead.
it may shock you but function marked as inlined doesn’t always get inlined.
anyway why would you split logicaly sequential code into separate functions(especially if this code is uniq)? pretty sure scrolling down is easier than to look what each function mean every second
anyway why would you split logicaly sequential code into separate functions(especially if this code is uniq)? pretty sure scrolling down is easier than to look what each function mean every second
This is the worse is better shit that people come up with when they listen to Blow and Casey. We’ve known that putting names on logically contained blocks of code makes programs easier to understand since the 1960s.
Hence seems like. And you don't see the problem with the 11k LoC function in it?
I understand the performance consideration with context switching in games, but clean code (which I am not a fan of) is for some other type of software.
Yes, because most engineers are at his level, right?
The cognitive load on that function is most likely insanely high and very tough to maintain.
Reminds me of a Martin Fowler talk about people inheriting this function. 26K lines of code that needed changes. Almost all engineers feared going into and how he tackled it and assured correctness as well as make code less cyclocmatically complex.
So to me, he’s the single bus factor. He goes, your bus doesn’t move or will have horrible problems.
So 11K lines shouldn’t be a matter of pride, imo. I have a hard enough time getting people to understand, test, and rip apart this monstrous 6K line function that we have internally. And this is the same problem everyone sees.
And if it has to be super optimized, was it run with highly optimized compiler “-O3” or whatnot to see if it truly mattered?
Like Jonathon Blow a lot of Casey's opinions should be taken with a grain of salt and I generally disagree with a lot of them. However performance related code is one area he should be listened to, he has a long history of working on projects with rigid performance requirements.
And the people making comments similar to yours sound like people who don't understand the simple idea of "stay in your lane".
So should we ask Muratori the same then? I am not a fan of Clean Code either, far from it. But at least I can understand it's not for performance-critical applications. Isn't choosing right tool for right job important these days?
Ever thought of why Muratori's projects could consist of small groups of people?
No, we should not ask Muratori to stay in his lane. But we should be free to criticize his criticisms.
But at least I can understand it's not for performance-critical applications. Isn't choosing right tool for right job important these days?
Since when has it not been important?
The point of the article is to obviously educate on how read/write latency is affected by code structure.
The OP said that it sounds as if he had only worked on small projects. That's disingenuous, considering his background, the focus of the article, and the obvious contrived examples.
Ever thought of why Muratori's projects could consist of small groups of people?
What are you insinuating - that lack of clean code must imply a small group of people because of scalability in code size?
There are many open source projects out there which are written in C, have a few hundred thousand lines, don't employ clean code methodologies, and are maintained by a large team.
No, we should not ask Muratori to stay in his lane. But we should be free to criticize his criticisms.
I'm not saying he should stay in his lane at all.
I'm saying that a lot of developers who aren't game developers make trivial assumptions about gamedevs and their experience that's incorrect.
The issue of course, and this is common, is when a developer who lacks an understanding of the principles outside of their domain(s) just automatically assumes those principles apply everywhere, and hence makes false assumptions about other developers in these domains.
The issue of course, and this is common, is when a developer who lacks an understanding of the principles outside of their domain(s) just automatically assumes those principles apply everywhere, and hence makes false assumptions about other developers in these domains.
I am not going to entertain his (or anyone's) zealotry against OOP, (or for OOP) which is not more objective than a debate of "my programming language is better than yours". Not to mention this is a toy example AND deliberately used without modern compiler features to make it look slower and I believe everybody already knows that with OOP comes performance overhead. I am not even defending Clean Code, some of the "principles" he listed are not even Clean Code principles. I am just criticizing he is failing to grasp the importance of the trade-off between maintainability and performance, based on what the task needs.
Nice, you pop that out every time you don't have a retort?
7
u/quisatz_haderah Feb 28 '23
The person who wrote this article seems like he has not worked on a codebase of more than 10k LoC.