Casey Muratori is wrong about clean code (but he's also right)
First things first...
I'd like to get one thing out of the way. Despite the click-bait headline, I think that Casey is right about a lot of things. It seems to me that programming for performance is becoming a lost art and I think Casey is doing great work as an advocate for writing code designed to perform well. So I agree with many of the principles he talks about and feel that he is shining a light on how non-performant most of the code we see today is. I hope he continues to do this. As someone who self-identifies as a developer who loves to optimize code and squeeze every last bit of speed out of it, I find myself nodding along with many of his points. Everyone should read his blog post at https://www.computerenhance.com/p/clean-code-horrible-performance too see a good demonstration of how he uses his principles to squeeze a ton of performance out of one of the first examples of OOP that beginners get shown in school.
I wouldn't be writing this unless there was a "but", so here we go :-). Spoiler alert, in the end, it's complicated and there are no hard and fast rules. Always profile your code to know what is fast and what isn't!
UPDATE: A reader on reddit pointed that the shapes were in a predictable pattern. So I've added one last section to the end to test again with some randomization. The results continued to surprise!
Read More...