Good point, the code locality is very important for maintainability down the road. When a single logical unit of functionality is unnecessarily split up across a file or even worse split into multiple classes it makes it much harder to understand.
I think a balance is possible. I tend to prefer to decompose functions for readability. A series of simple sequential function calls that describe what they do is more quickly readable than the same instructions listed as a series of compound operations.
These function definitions are also typically defined in call order in the same file.
If you need to know what the individual functions do you can scroll down the necessary few lines , but IMO as long as you name your functions honestly that isn't generally required to be ablr to understand what both what it's doing and where you're likely to need to make your change/fix at a glance.
This style does require a lot of trust that everyone is following the same strategy - as soon as you have to doubt that accuracy of a named function in this approach, the benefit is lost. So it becomes important to keep them up to date - changing what function does must also change its name.
Thank you. I find layered stuff much easier to understand than massive clutter with "housekeeping" and "domain logic" stirred together, as well.
My IDE allows me to leave the "documentation" panel open attached to a side of the window. As the cursor/caret touches an identifier, the documentation for that function/method or constant/variable appears automagically. But of course, I type reasonably well and write Javadoc/JSDoc on my stuff, so there is something to see. Others seem to rely on gargantuan "self documenting" (bullshit!) identifier names for the IDE to auto-complete, rather than actual documentation. Pet peeve.
Sure, and it's great when a balance is struck. Too often, at least in my experience, the smaller chunks get shuffled out of the same file and into a nightmarish Rube Goldberg concoction in "utils" modules, packages and whatnot. I use primarily compiled C-like languages (C, C++ and Rust, specifically). I tend to put chunks of code that might be candidates for factoring out in their own scope block with a comment. Then, if the function really does become "too big" (for the very subjective measure that is), bits can be factored out on an as-needed basis.
