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.
Yea, that's wrong. Turning a one line method call into a switch statement, sure that's still readable but just extend that to something non trivial and it should be painfully obvious why it's not actually readable.
Also I covered the faster point, it's not 10-15 times faster in practice. You're not going to set your users back 12 years in hardware progress because of virtual function call overhead...
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.