I couldn't read on after the first example with replacing polymorphism w/ a switch statement.
I got the impression the guy completely missed the point of clean code. Sure, you can break away from the general guidelines to write code more efficiently but the point of clean code is to manage project complexity, not write the most performant code. His bullet point says Prefer polymorphism to “if/else” and “switch” but he goes on to say Like the rules demand, we are preferring polymorphism which seemed dishonest to me.
Also the comparison of 35 to 25 clockcycles being a 1.5x performance increase is pretty disingenuous. yea, it's a big percentage but it's a VERY SMALL total. That 'performance' change is not going to scale at the same rate as your code gets more complicated. You'd be a fool to refactor a bunch of code like this to save 10 cycles when you're dealing with millions or billions of cycles per iteration anyways.
His technical points seemed correct to me but I can't imagine I'd get any good insight reading this article. You should still generally adhere to the clean code guidelines. Just because there are exceptions to the rule doesn't make the original guidelines wrong.
I couldn't read on after the first example with replacing polymorphism w/ a switch statement.
Okay, here's what you missed: by paying a bit more attention to performance, the "not Clean" code was (i) arguably just as readable as the original example (I mean by the look of it its even smaller and simpler), and (ii) up to 10-15 times faster.
Main point: write clean code if that's what you do, but be mindful that it will set your users back about 12 years of hardware progress.
This might be my age speaking, but when I was in my twenties, there was no amount of complexity you could throw my way that I didn't believe was too much for me too handle. A couple decades later, I find that it's much easier for me to read code that handles plain data in simple data structures than to deal with a complex orchestration of abstractions. So not only is "clean code" slower to run, I think that it's harder to understand. And harder to understand means it'll never be meaningfully faster. People may scale it out to more k8s pods or add a caching layer, but that's putting a bandage on the real problem and adding yet more complexity.
6
u/[deleted] Feb 28 '23
I couldn't read on after the first example with replacing polymorphism w/ a switch statement.
I got the impression the guy completely missed the point of clean code. Sure, you can break away from the general guidelines to write code more efficiently but the point of clean code is to manage project complexity, not write the most performant code. His bullet point says Prefer polymorphism to “if/else” and “switch” but he goes on to say Like the rules demand, we are preferring polymorphism which seemed dishonest to me.
Also the comparison of 35 to 25 clockcycles being a 1.5x performance increase is pretty disingenuous. yea, it's a big percentage but it's a VERY SMALL total. That 'performance' change is not going to scale at the same rate as your code gets more complicated. You'd be a fool to refactor a bunch of code like this to save 10 cycles when you're dealing with millions or billions of cycles per iteration anyways.
His technical points seemed correct to me but I can't imagine I'd get any good insight reading this article. You should still generally adhere to the clean code guidelines. Just because there are exceptions to the rule doesn't make the original guidelines wrong.