4 ms·

Obviously, both of your extremes are totally unmaintainable and it doesn’t matter which somebody prefers of the two. What I think matters in the general case i

Obviously, both of your extremes are totally unmaintainable and it doesn’t matter which somebody prefers of the two. What I think matters in the general case is the likely mutation rate of the code, and the familiarity of its design. Both of these are speculative, subjective factors, so right-sizing a function is basically a gut feeling. It can prove wrong in hindsight and others can disagree with your choice from the get-go. So it goes. But a library function that won’t need much maintenance and implements a well-known pattern, style, or algorithm can safely be much longer than something that’s likely to see a lot of change (especially by other people) or that’s very unusual.

riffraff 4y ago
> Obviously, both of your extremes are totally unmaintainable and it doesn’t matter which somebody prefers of the two. But we work with 1000 five lines functions all the time in high level languages. All the stuff done on array/list/hash and the likes (map,fold/inject/reduce,sum,select,reject..) are five lines functions. Why would you not want that for your own types?
- swatcoder 4y ago
  If they’re operations used in a hundred places, then they should be whatever size they need to be. Of course there are a lot of 5-line functions in that set, and also some 500-lines functions and also many functions that recurse or stack very deeply, and also some very shallow ones. They’re polished stones. But function length isn’t a useful goal in itself and if it’s made to be, you’re deprioritizing the many other factors that matter.