[riwsky]

Sure, comprehensibility is the terminal goal—but size reduction is relevant because it’s an easily measured, decently predictive proxy for that. No, code-golfing 3 lines down to one doesn’t help, but the bigger size differences are always of the “composition over XYZ” variety that change the entire complexity class of how much code you need to write (like React letting people write O(states) rendering code instead of O(transitions)).

[_a_a_a_]

Size reduction usually follows but not necessarily. That is easily measured is an irrelevance. The claim that its a decently predictive proxy I can't buy at the moment, can you try justifying that? Some very terse code can be very hard to understand without (comprehensive) commenting eg. https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...

Maybe you're right. I've had a drink, I'll think over it in the morning, thanks.

[jholman]

If you don't care about performance, we can make that code a lot shorter.

  float Q_rsqrt(float number) {
    return 1 / sqrt(number);
  }

The "fast inverse square root" is absolutely 100% all about performance. For it to make sense to use as a counter-example, you need to show alternate code that still meets the contract (the contract being: be as fast as this code), that is longer, and clearer.

[_a_a_a_]

I was saying that shorter code is not necessarily more readable. But what you're talking about is optimisation and I'm fine with that, uglier code for higher speed (or whatever). But is that refactoring? I don't think so. I may have led you a bit down the garden path here.