What I didn't like about the "Clean code, horrible performance" video is that he talked about "clean" code as though it was this unjustified, useless way of thinking about programming. This is maybe something you have to think about if you want the most performant code possible, but I don't think it's a good mantra in all situations the way it's presented in the video. Number one priority should always be "understandable code". If you aren't always thinking about the best way to get your point across to future programmers (including yourself) you're going to have a bad time.
back
1 comments
> he talked about "clean" code as though it was this unjustified, useless way of thinking about programming.
That was kind of the point. There is no empirical evidence showing that the "clean code" way of programming is any better in terms of cognitive load, but there is empirical evidence that it makes your program perform very poorly.
The video also did not aim to produce "the most performance code possible", which would certainly become a tangled web of arcane bit tricks and CPU minutiae. It was demonstrating what reasonable performance might look like, if you wrote simple code that the compiler can do a good job at optimizing.
In addition, he demonstrated very clearly that doing it the "clean" way was significantly worse in terms of being able to see that the optimizations he did were even possible, so, that observation argues that the "clean" principals not only make your code slow as shit, but ALSO harder to reason about.
I program in a similar style to Casey all day, every day, and I typically have no trouble going to code I wrote years ago and figuring out what's going on.
If that doesn't convince you that it's an unjustified and useless way of thinking about programming, I'm not sure what would.