4 ms·

I don't think any such benchmark should exist. As long as the function only does one thing there is no upper limit. Artificially splitting a large function only

by jeltz 2mo ago

I don't think any such benchmark should exist. As long as the function only does one thing there is no upper limit. Artificially splitting a large function only reduces readsbility. What would you name the parts? do_stuff1(), do_stuff2(), do_stuff3()? I have seen very clean codebases with a handful very long functions, but they were no issue she nice they only did one thing. I personally write quite short functions but I have never understood why people take issue with large functions. Those are one of the easiest things to fix in a bad codebase. It is much harder to clean up after someone who used too small functions.

azertify 2mo ago
There aren't usually many domains where a process can't be described as a series of steps. Deciding what those are called, and structuring data in such a way that it each of those steps works sensibly can be challenging, but that is the process of making code comprehensible. I can remember as a novice that I would write an entire program in a single, many-thousand line function, unable to see where the boundaries between functions should be. With experience and expertise in the domain, it becomes easier to see where those should be.
tcfhgj 2mo ago
> What would you name the parts? do_stuff1(), do_stuff2(), do_stuff3()? depends on what the function does, most likely the best decomposition into functions isn't simply splitting the function in to n sequential parts > I have seen very clean codebases with a handful very long functions, but they were no issue she nice they only did one thing. one thing usually consists of multiple other things imho length should correlate negatively with cyclomatic complexity - it's ok if you write 300 locs if all you do is fill a map with trivial entries
Someone 2mo ago
> I don’t think any such benchmark should exist. wing-_-nuts says (emphasis added) “My personal benchmark for 'MAYBE this function is too long' is when it doesn't fit on the page.”. I think that’s a fine heuristic. Long functions can be fine, but longer functions tend to be less testable, so you should try to avoid them. On the other hand, it can take lots of thinking to properly decompose functionality, and that decomposition can easily change when requirements change, so spending that time may not be worth it.

by jeltz 2mo ago

azertify 2mo ago

There aren't usually many domains where a process can't be described as a series of steps. Deciding what those are called, and structuring data in such a way that it each of those steps works sensibly can be challenging, but that is the process of making code comprehensible. I can remember as a novice that I would write an entire program in a single, many-thousand line function, unable to see where the boundaries between functions should be. With experience and expertise in the domain, it becomes easier to see where those should be.

tcfhgj 2mo ago

> What would you name the parts? do_stuff1(), do_stuff2(), do_stuff3()? depends on what the function does, most likely the best decomposition into functions isn't simply splitting the function in to n sequential parts > I have seen very clean codebases with a handful very long functions, but they were no issue she nice they only did one thing. one thing usually consists of multiple other things imho length should correlate negatively with cyclomatic complexity - it's ok if you write 300 locs if all you do is fill a map with trivial entries

Someone 2mo ago

> I don’t think any such benchmark should exist. wing-_-nuts says (emphasis added) “My personal benchmark for 'MAYBE this function is too long' is when it doesn't fit on the page.”. I think that’s a fine heuristic. Long functions can be fine, but longer functions tend to be less testable, so you should try to avoid them. On the other hand, it can take lots of thinking to properly decompose functionality, and that decomposition can easily change when requirements change, so spending that time may not be worth it.