Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.
A nice thing about code length is it’s objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.
It takes a damn good abstraction to beat having shorter code.
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.
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.
but we can agree on which of two implementations is shorter.
Shortness for the sake of being short sounds like optimizing for the wrong metric. Code needs to be easy to read, but it’s more important that the code is easy to change and easy to test. Inline code and function calls are renowned to render code untestable, and introducing abstract classes and handles is a renowned technique to stub out dependencies.
shorter code is not always better, especially when it comes to types. building in lots of guard rails by being verbose with the type system is a good thing. “shorter = better” is the python approach that starts off fun and easy but the codebase scales extremely poorly.
Shorter code is almost always better.
Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.
A nice thing about code length is it’s objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.
It takes a damn good abstraction to beat having shorter code.
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.
Shortness for the sake of being short sounds like optimizing for the wrong metric. Code needs to be easy to read, but it’s more important that the code is easy to change and easy to test. Inline code and function calls are renowned to render code untestable, and introducing abstract classes and handles is a renowned technique to stub out dependencies.
shorter code is not always better, especially when it comes to types. building in lots of guard rails by being verbose with the type system is a good thing. “shorter = better” is the python approach that starts off fun and easy but the codebase scales extremely poorly.
Golfing is optimization.
I spent years writing an abstraction to be able to write shorter code… Not sure whether that was worth it 😅