Some notable exceptions are things like addresses where many times users have multiple, but usually people splitting up the user table and the "user profile" table are just causing headaches. A wide user table is fine.
Premature method or function isolation: Usually good.
Even if there isn't reuse, the code is usually more readable.
def let_in_bar?
return self.is_of_age_in_region? and self.is_sober?
Is a perfectly fine isolation with very little downside.
I know your example is just a toy, but it definitely reminds me of heavy handed over-refactoring into tiny one-line functions.
There are two problems with that approach:
The first is when you're trying to understand what a single function does. If it's 20 lines long but has self-contained logic, that's often easier to understand than referring back to the tiny pieces it's assembled from (even if they're supposedly so self contained you don't need to look at them individually - that's rarely true in practice). On balance, even if a function is a slightly too long, that's usually less bad than one that's in slightly too many little pieces.
The second is when you're looking at the file level. When faced with a file with dozens of tiny functions, it's much harder to get a top level understanding than if it has a smaller number of longer functions.
The second one is the bigger problem, because understanding a project at the file (and higher) level is typically much harder than understanding what a single function does. Even if breaking up a function into smaller pieces does actually make it easier to understand, but makes the overall project harder to parse, then that's usually a loss overall. Of course, it depends very much on the specifics of the situation though, and certainly a long function broken down into logical pieces can actually make the overall project easier to understand.
It's relatively rare to refactor a single line of code into its own function, unless it's really hard to read, e.g. some nasty regex.
> even if they're supposedly so self contained you don't need to look at them individually - that's rarely true in practice
If a long function is broken up into smaller functions only for the sake of having smaller functions, then you end up with functions that don't really make sense on their own and, sure, the bigger function is better. But if the broken up functions are named well enough like in the example above, then it shouldn't be necessary to see how it's implemented, unless you're tracking down a bug. After all, it's very rare to look at e.g. how a library function is implemented, and for some libraries/languages it's not even possible.
> When faced with a file with dozens of tiny functions, it's much harder to get a top level understanding than if it has a smaller number of longer functions.
Most languages have facilities to help with that, e.g. function visibility. Your smaller number of large functions can remain the public API for your module while the "dozens" of tiny functions can be private. In either case, long files are harder to take in no matter how many functions they're composed of.
> But if the broken up functions are named well enough like in the example above, then it shouldn't be necessary to see how it's implemented, unless you're tracking down a bug.
(Emphasis added.) Yeah, exactly. Tracking down a bug is one of the times that code clarity is most important, and over eager abstraction is most annoying.
Some notable exceptions are things like addresses where many times users have multiple, but usually people splitting up the user table and the "user profile" table are just causing headaches. A wide user table is fine.
Premature method or function isolation: Usually good.
Even if there isn't reuse, the code is usually more readable.
Is a perfectly fine isolation with very little downside.