alt Hacker NewsI 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.
Replies
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.
> 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