4 ms·
My feelings on LoC really depend on what you want to measure. LoC tends to correlate with # bugs. A 100-line function is probably going to have more bugs than a
by tyleo 1y ago
My feelings on LoC really depend on what you want to measure. LoC tends to correlate with # bugs. A 100-line function is probably going to have more bugs than a 20-line function that does the same thing.
I don’t think functions inherently need to be small though. 5 20-line functions are just as buggy as that 1 100-line function. Bugs scale with LoC, not how well you’ve broken functions apart.
The lesson is really just to avoid overcomplicating things. Use less LoC if you can. You should also avoid overly-shortening or cleverness but it tends to be the lesser evil.
- tekne 1y agoI’d hazard that the 5 20 line functions are sometimes slightly less buggy, since the function signatures act as essentially an enforced comment on how the implementation is done and perhaps which state is accessed/modified. Versus mutable variables and if-statements in the larger function, that is.
- tyleo 1y agoI’d say more testable. I haven’t seen any metrics on amount of bugs vs composability of functions though. There are metrics on amount of bugs vs LoC. I have a personal preference towards the “more functions” approach too but I want to separate out my emotional feeling about what’s better vs what’s actually supported with data.