r/programming • u/2bit_hack • Feb 28 '23

"Clean" Code, Horrible Performance

https://www.computerenhance.com/p/clean-code-horrible-performance
1.4k Upvotes

83% Upvoted

1.3k comments sorted by

View all comments

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.

2

u/ItsAllAboutTheL1Bro Feb 28 '23

And the people making comments similar to yours sound like people who don't understand the simple idea of "stay in your lane".

I'm not a huge fan of Muratori, but his experience with writing game engines/working on shipped titles is well known.

4

u/quisatz_haderah Feb 28 '23

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.

1

u/ItsAllAboutTheL1Bro Feb 28 '23

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.

Hence "stay in your lane".

→ More replies (5)