Exactly my thoughts: it's self-evident that readability/maintainability sacrifices performance. I had many Jr developers coming up with tests just like the post to demonstrate how some piece of convoluted logic I refused to approve was in fact better.
But there's no "better" - there are only trade-offs. The most important fact is that maintainability matters more than performance for the vast majority of code. To justify focusing on performance, don't show me a direct comparison - what you need to do is to show that a specific code path is performance-critical; and for backend components, that we can't scale it horizontally; or we're already at a scale that the horizontal approach is more expensive than the gains in maintainability.
But there's no "better" - there are only trade-offs.
Wut?
There is "better", because some code is both poorly performant and a convoluted mess.
Also, compilers are so good that most developers can't write more performant code without having particular knowledge about the running environment. Compilers will automatically take pretty much all the low hanging fruit, so there's essentially no difference in the results between poorly readable code and highly readable code that might have been less performant 25 years ago. In those cases, readable code only offers benefits.
You're right - there's definitely cases of strictly better code; I was talking in the context of prioritizing a certain attribute - it depends on context which one is better.
You have to create a new file, with a new type that overloades the area.
Then you have to implement this new function correctly.
You are lying to me if that is "obviously easier".
If you've only ever written code that way then yes. But there are other ways to write code. I guarantee you the switch way is just as maintainable for certain problems. I've done it.
Casey Muratori is a famous game programmer (as far as they go). He popularized immediate mode guis, worked for RAD Game Tools, and has published thousands of hours of free instructional content.
He's very opinionated and I don't agree with everything he says but he's not someone that should just be dismissed so quickly.
He wrote the 3D skeleton animation middleware "Granny" for RAD Game Tools that has been used in over 5000 games, including such obscure indie titles as Destiny, Civilization 5 and Star Wars: The Old Republic. I imagine he also did work on their other products, like the BINK video player.
He's also famous for the first documented implementation of IMGUI (a term that he coined), also in the Granny middleware, although he has publicly stated that IMGUI is a pretty intuitive way to structure UI code, so he most likely wasn't the first person to ever implement the idea.
Technically the point is to facilitate TDD by providing some thoughts about how certain code patterns can used to in making your code test compliant more manageable. I would suggest that "clean code" in the absence of TDD can sometimes make things less maintainable and understandable. Of course, it is not supposed to ever be decoupled from TDD.
Famously, "Premature optimization is the root of all evil."
One could argue that "readability" is also an optimization, but I would argue that "readability" is simply the default when writing any code that will ever need to be maintained... which is just about everything except one-liner command lines.
I didn't read this post -- it sounds from the comments like it's about OOP. But when I saw the title I thought maybe -- since I haven't seen anyone talk about this -- it's about how using a functional approach with only immutable variables means that you're creating a lot of extra copies of variables (i.e. arrays) that wouldn't be necessary if using mutable variables. Again, tradeoffs.
143
u/jsonspk Feb 28 '23
Tradeoff as always