Function Length Debate

I'll take a 30k line function that does one thing over 30 1k line functions that are used once...

I'm with you re. short functions. Setting boundaries around code, i.e. scope, and giving that behaviour a well-defined signature (i.e. a descriptive name, what it needs, and what it gives back) makes it easier to reason about the overall functionality. Giant functions reduce my confidence that any given change isn't going to introduce a problem.I like to imagine each execution path through a function as a piece of string. The fewer strings, the fewer kinks, and the less string overa

Have you considered not writing functions longer than 3 lines?

If you're trying to split up a 16 line function into multiple functions and having trouble doing it, instead of claiming the original code is bad, maybe you should consider that the original code is good and you just shouldn't be splitting up the function...

4 line functions everywhere is insanity. yes, you should aim for short functions that do one thing, but in the real world readability and maintainability would suffer greatly if you fragment everything down to an arbitrarily small number.

Apologies. I wasn't clear. I meant it's a stretch to approve a function that's 600 lines. It would be very hard to reason about. I have clarified in my original post. Thank you for the feedback +1 to you.

I disagree with the use of lots of small 1 line functions, especially when doing algorithmic work.As the article mentioned, the thing you spend most of your time doing is reading. Using lots of small functions means you have to bounce all over your codebase to figure out whats actually going on. In procedural languages a complex 'meaty' function often needs to be understood in one conceptual bite. Needing to bounce all over the codebase to figure out what those little functions are

I too find the code on the left/red (linear) more readable. However the version with all the functions is quite extreme. When I'm splitting my code into functions I decide if something should be it's own function on the basis of: is this chunk of functionality required to be reusable? Am I repeating code, only slightly changed?If the answer is yes, a function gets created. I never do what I assume authors did here, find the smallest logical units code can split into and generat

It's about eliminating cognitive load when reading and/or modifying source later. The more code you can eliminate from what is being looked at, the easier it is for the reader to understand the purpose of the function and what it is accomplishing.At some point, someone is going to need to change your code. When that happens, it is easier to 'surgically' modify a single method that does one simple thing, than adjust one tiny piece of a much larger function. Even though the

> 1. Don't use a bunch of tiny functions. This makes it harder for future eng to read the code because they have to keep jumping around the file(s) in order to understand control flow. It's much better to introduce a variable with a clear name.If you have nested functions, that's not a problem.Btw, why do you use regular expressions for some rules, but not for others? Regular expressions are perfectly capable of expressing the length requirement.