I wouldn't have asked if I didn't have a real curiosity!
To use a real world example where this comes up a lot, lots and lots of code can be structured as something like:
accum = []
for x in something():
for y in something_else():
accum.append(operate_on(x, y))
I find structuring it like this much easier than fully expanding all of these out, which at best ends up being something like
accum = []
req = my_service.RpcRequest(foo="hello", bar=12)
rpc = my_service.new_rpc()
resp = my_service.call(rpc, req)
req = my_service.OtherRpcRequest(foo="goodbye", bar=12)
rpc = my_service.new_rpc()
resp2 = my_service.call(rpc, req)
for x in resp.something:
for y in resp2.something_else:
my_frobnicator = foo_frobnicator.new()
accum.append(my_frobnicator.frob(x).nicate(y))
and that's sort of the best case where there isn't some associated error handling that needs to be done for the rpc requests/responses etc.
I find it much easier to understand what's happening in the first case than the second, since the overall structure of the operations on the data is readily apparent at a glance, and I don't need to scan through error handling and boilerplate.
Like, looking at real-life examples I have handy, there's a bunch of cases where I have 6-10 lines of nonsense fiddling (with additional lines of documentation that would be even more costly to put inline!), and that's in python. In cpp, go, and java which I use at work and are generally more verbose, and have more rpc and other boilerplate, this is usually even higher.
So the difference is that my approach means that when you jump to a function, you can be confident that the actual structure and logic of that function will be present and apparent to you on your screen without scrolling or puzzling. Whereas your approach gives you that, say, 50% of the time, maybe less, because the entire function doesn't usually fit on the screen, and the structure may contain multiple logical subroutines, but they aren't clearly delineated.
To use a real world example where this comes up a lot, lots and lots of code can be structured as something like:
I find structuring it like this much easier than fully expanding all of these out, which at best ends up being something like and that's sort of the best case where there isn't some associated error handling that needs to be done for the rpc requests/responses etc.I find it much easier to understand what's happening in the first case than the second, since the overall structure of the operations on the data is readily apparent at a glance, and I don't need to scan through error handling and boilerplate.
Like, looking at real-life examples I have handy, there's a bunch of cases where I have 6-10 lines of nonsense fiddling (with additional lines of documentation that would be even more costly to put inline!), and that's in python. In cpp, go, and java which I use at work and are generally more verbose, and have more rpc and other boilerplate, this is usually even higher.
So the difference is that my approach means that when you jump to a function, you can be confident that the actual structure and logic of that function will be present and apparent to you on your screen without scrolling or puzzling. Whereas your approach gives you that, say, 50% of the time, maybe less, because the entire function doesn't usually fit on the screen, and the structure may contain multiple logical subroutines, but they aren't clearly delineated.