We might further expand the model in my previous comment with "units of comprehension". You might do five operations (each costing one unit of comprehension) in one line or in five lines. If it's one terse clever line, that's basically the same thing as five simple lines because there's the same amount of comprehension cost. The clever line might actually be penalized if it's not immediately clear that it's doing five things at once (and if it's clever, that implies it's not immediately obvious).
However, you might instead pack those five simple lines into a function that you give a good descriptive name. Now although the computational units are unchanged, the work now sometimes only costs one comprehension unit if the programmer working with the code understands at a sufficient-for-their-needs level what's going on from the function name/signature without needing to delve into implementation details. The difference between that and the terse clever line is that the terse clever line is still implementation whereas the function is descriptive abstraction.
This is of course very rough pretend-math and there are plenty of real-world cases where function names aren't descriptive, but hopefully conveys the idea of how you can reduce the code you need to read without needing to resort to cleverness.
On a documenting perspective, having the well named function contain five lines of simple operations will look better than the terse 1-in-5 line.
To me the catch is that the reader/reviewer will need to trust the function actually does what it is named after. Otherwise they'll need to go look at the 5 lines anyway, and it might be more costly to go navigate to the function and come back than reading the same content inline.
With that 5-in-1 terser (that's such an horrible compression ratio BTW) line, there is no need for blind trust. It might need more effort to understand, but you also don't have the burden to associate the name of the function with what it actually does (even aptly named functions will still have some gap with what they do or don't). I'd hold my head while decrypting that 5-for-1 bundle while cursing the world, but I'd also see that as a very pragmatic and reasonable choice if it relies only on standard libraries and don't abuse undefined or deprecated behaviors.
BTW I'd still go with a separate function containing the longer code if it helps for tests for instance. As everything and as you point out, real-world cases are always more complex and nuanced.
Comments
We might further expand the model in my previous comment with "units of comprehension". You might do five operations (each costing one unit of comprehension) in one line or in five lines. If it's one terse clever line, that's basically the same thing as five simple lines because there's the same amount of comprehension cost. The clever line might actually be penalized if it's not immediately clear that it's doing five things at once (and if it's clever, that implies it's not immediately obvious).
However, you might instead pack those five simple lines into a function that you give a good descriptive name. Now although the computational units are unchanged, the work now sometimes only costs one comprehension unit if the programmer working with the code understands at a sufficient-for-their-needs level what's going on from the function name/signature without needing to delve into implementation details. The difference between that and the terse clever line is that the terse clever line is still implementation whereas the function is descriptive abstraction.
This is of course very rough pretend-math and there are plenty of real-world cases where function names aren't descriptive, but hopefully conveys the idea of how you can reduce the code you need to read without needing to resort to cleverness.
I think I get your point.
On a documenting perspective, having the well named function contain five lines of simple operations will look better than the terse 1-in-5 line.
To me the catch is that the reader/reviewer will need to trust the function actually does what it is named after. Otherwise they'll need to go look at the 5 lines anyway, and it might be more costly to go navigate to the function and come back than reading the same content inline.
With that 5-in-1 terser (that's such an horrible compression ratio BTW) line, there is no need for blind trust. It might need more effort to understand, but you also don't have the burden to associate the name of the function with what it actually does (even aptly named functions will still have some gap with what they do or don't). I'd hold my head while decrypting that 5-for-1 bundle while cursing the world, but I'd also see that as a very pragmatic and reasonable choice if it relies only on standard libraries and don't abuse undefined or deprecated behaviors.
BTW I'd still go with a separate function containing the longer code if it helps for tests for instance. As everything and as you point out, real-world cases are always more complex and nuanced.