HELL NO! If you split that function into three, but these always have to be called in succession, you win nothing but make your code WAY harder to read/follow.
Well named functions, called in succession increase readability, not decrease.
What do you gain from that approach, compared to comments, and appropriate whitespace? If you spread out your function over three, you now potentially have triple the moving parts. You have to manage in- and output, and you have to hope noone coming after you sees your subfunction, and assumes it's there for using.
Testability for one, but I would also argue that those functions are there for using. If some block of logic is sufficient to stand on its own, it should. I'm not saying do it arbitrarily, but it's been my experience that small functions lead to more readable code and better testing. Most people write a 15 line function treating it as if it does a single thing when in reality it's doing two or three discrete operations
HELL NO! If you split that function into three, but these always have to be called in succession, you win nothing but make your code WAY harder to read/follow.
Well named functions, called in succession increase readability, not decrease.
What do you gain from that approach, compared to comments, and appropriate whitespace? If you spread out your function over three, you now potentially have triple the moving parts. You have to manage in- and output, and you have to hope noone coming after you sees your subfunction, and assumes it's there for using.
Testability for one, but I would also argue that those functions are there for using. If some block of logic is sufficient to stand on its own, it should. I'm not saying do it arbitrarily, but it's been my experience that small functions lead to more readable code and better testing. Most people write a 15 line function treating it as if it does a single thing when in reality it's doing two or three discrete operations