On Wed, Mar 1, 2023 at 7:42 AM Kate Gregory via SG20 <sg20@lists.isocpp.org> wrote:

Part of the issue here is that we have normalized so much of this decades-old advice that the comparisons are not what they once were.

 

Take a simpler piece of advice like declaring things immediately before you use them, or at least closer to where you use them. I’ve had arguments and pushback on this from people who are writing functions that are at most 20 lines long. When I tell them about 5000 line functions they just can’t believe me. And the worst of those functions that were thousands of lines long always seemed to have a giant switch, with each case screens and screens long, or nested loops again screens and screens long.


+1.

Also, notice what the presenter says @21:30: These ("clean code") rules were designed to produce more maintainable codebases. So naturally they'll tend to produce less performant codebases — that's just the nature of "pick-two triangles." Every time you hear "I'm optimizing for X," you should understand that it means "I'm pessimizing for Y and Z."

In this particular context, I'd say the relevant triangle is
1. Abstraction (clarity of high-level)
2. Understandability (clarity of low-level)
3. Performance
where the particular "Clean Code" style he's targeting is clearly optimizing for 1 and 2 together (and thus, not even a little bit of 3).
I'm sure we all know programmers (many of them on the committee) who enjoy targeting 1 and 3 together (and thus, not even a little bit of 2) — in the context of this example, it'd be someone who writes a vectorized algorithms library to replace that 4x-unrolled `for` loop.
The presenter's optimizations in this talk are focused mainly on giving up 1 to achieve better 3 (while leaving 2 only a little worse off, IMHO).

In big industrial codebases, 1 and 2 are really important, and 3 tends to be deprecated in practice. Cynically, one might say that that's because 1 and 2 operate on the labor side — they reduce the difficulty of the worker's job — and 3 operates on the capital side — it increases the value to the employer of the finished product. So naturally when you (A) distinguish the worker from the employer and (B) give the worker free rein to optimize 1+2+3 in any way they see fit, well, they'll improve 1 and 2 and decrease 3, every time.

This also explains the existence of "10x programmers," in the sense of a programmer who's 10x better than their peers at whatever metric you happen to care most about. As this presentation shows, it's very very easy to get a 10x or even 20x improvement in one metric by completely discarding another. If your boss values the improved metric while not knowing about the discarded one(s), then he'll see you as a "10x" or "20x" programmer, by definition.

Of course every feature is a tool, and as a tool, it should be used for its intended purpose. If you're using polymorphism and not reaping the benefits of polymorphism (open hierarchy, understandability, abstraction), then you're reaping only the costs. If you're writing 10-line functions and not reaping the benefits of 10-line functions (understandability, testability), then you're reaping only the costs. Reap enough costs without any matching benefits, and your code can get worse on all three metrics simultaneously without getting better at any of them.

my $.02,
–Arthur