I mostly agree with this but more than shorter code I value readability, I would rather take 3 lines to be clear to any developer than use some obscure or easy to misunderstand structure to write it in 1.
Yep. And three functions is better than one for legibility even if one would be fewer lines of code
I think it really depends. Functions break up the visual flow, so if you need to look at multiple functions to visualize one conceptual process then it can be less efficient
Yes. I learned this from Haskell. I like Haskell, but it has a lot of very granular functions.
Earlier comment said that breaking up 1 function into 3 improves readability? Well, if you really want readability then break it up into 30 functions using Haskell. Your single function with 25 lines will become 30 functions, so readable (/s).
In truth, there's a balance between the two. Breaking things up into function does have advantages, but, as you say, it makes it more likely that you'll have to jump around a lot to understand a single process.
I specifically have a rule that if at the current abstraction layer, a step is more than one function call/assignment - I'm creating another function for that.
I think they didn't mean how you structure your code but actually precision.
I mostly agree with this but more than shorter code I value readability, I would rather take 3 lines to be clear to any developer than use some obscure or easy to misunderstand structure to write it in 1.
Yep. And three functions is better than one for legibility even if one would be fewer lines of code
I think it really depends. Functions break up the visual flow, so if you need to look at multiple functions to visualize one conceptual process then it can be less efficient
Yes. I learned this from Haskell. I like Haskell, but it has a lot of very granular functions.
Earlier comment said that breaking up 1 function into 3 improves readability? Well, if you really want readability then break it up into 30 functions using Haskell. Your single function with 25 lines will become 30 functions, so readable (/s).
In truth, there's a balance between the two. Breaking things up into function does have advantages, but, as you say, it makes it more likely that you'll have to jump around a lot to understand a single process.
I specifically have a rule that if at the current abstraction layer, a step is more than one function call/assignment - I'm creating another function for that.
I think they didn't mean how you structure your code but actually precision.