[UglyToad]

I think my problem with this approach and why I lean to favouring the more obvious and verbose comment is, if I'm reading the code it's probably because something is broken (or I need to change something in the area).

With the function I think, "is it and if it is what else does it change?". Is that function definition actually doing what it says it is? So now I have to add another stack frame to my mental model, go to definition on the function, confirm that is indeed what it claims to do, pop the frame and resume my reading of the parent method.

With the comment I get the statement of intent and can see if the code matches inline. Now it's fair to say a good code review culture (and immutability) might create code where there's more room to trust named functions, but I've not seen it yet.

[tharkun__]

I don't really get why your mental model is bothered more by the function/stack frame than the comment.

Whether I read a function name or comment personally that does pre occupy my mind and sets the mental frame for what comes next. If the comment or function name say doX() or //this does X then I expect it to do that but need to be on the lookout for whether it actually does that.

With a function though I can easily step out if this part turns out not to be interesting, I can easily step over it next round if debugging, I don't need to keep track of where //this does X ends etc.

Of course none of these help if the previous author was really bad at what they were trying to communicate. They can both implement doY() in a function called doX() and have //do Y code run in with //do X for example by interleaving statements for both. If we assume we'll intentioned authors for both though, I would tend to see more pros for structuring code with functions than via comments.

[nerdponx]

Stepping in and out is an extra step, mentally and physically. It's increased burden on my working memory, which is usually already quite full keeping track of other aspects of the task at hand.

Also it imposes more burden on the author, and possibly could lead to developing the wrong abstraction, which we all know is bad.

[tharkun__]

I don't get that. If you need to step over a function call you just remember 'oh right, step over doZ()' vs 'oh right this is 78 lines in which the code does Z, and dang I'm stepped 24 lines into it already before noticing. Where was the end of this again so I can skip ahead?'

One of those seems easier to me. Potentially our brains just work way differently but I have a much easier time remembering that function name I will step over.

[UglyToad]

I think this probably relates to fundamental differences in how people think. Like the "imagine an apple" test of people's mental modes of imagination.

I'm quite a visual thinker so I use the shape of the surrounding code to anchor my mental model of the code. If I have to jump to another file or function then I lose the shape and it disrupts my model. This is why on balance I (now) prefer longer functions over code split up.