How many lines is too many lines ?

[LV]

Here are my questions:

1. How many lines does it take for a function/procedure to be considered too long ?
2. Why is it too long ?  or IOW, why is it objectionable to have a function exceed that number of lines simply be summarily declared as "too long" ?  What made it too long ? just the number of lines ?
3. Can a function/procedure be too short ? and whatever the answer is, how is it justified ? (IOW, how is that answer justified ?)

🤔 The clear answer to the questions posed is that there are no clear answers. 😉

[Lauriet]

Well, you see, that's where you have missed the point. With a good procedure/function name you do NOT have to divert your attention anywhere, you automatically know what the bit of code does, 'cause it says so and tells you what data structure it uses.

You asked the question, why argue with any answers

Apparently you're the one who missed the point.  No matter how well named a function or procedure may be, that doesn't give all the details as to how it is implemented.

Maybe you are one of those people who simply does not care how it's implemented and as long as the thing is called "sort" you'll use it and believe it is doing a great job in spite of being a bogosort (and that's hoping it is actually a sort procedure and... it is bug free... that's what programming is all about... use stuff you don't check nor understand... way to go!.)

OK, I surrender. You obviously are not interested answers to your question.
Probably my fault, I didn't realise you are only 12.
You go ahead and write your 1000+ lines procedures.

[440bx]

You surrender ?? ,.. that's funny.  Thank you for the laugh.

[Zoran]

Looking into the first two pages of this thread, I'd say the real question here is -- how many lines in a forum post is too many lines?

[LeP]

Looking into the first two pages of this thread, I'd say the real question here is -- how many lines in a forum post is too many lines?

[Martin_fr]

Looking into the first two pages of this thread, I'd say the real question here is -- how many lines in a forum post is too many lines?

Well, one can always separate individual parts of a reply (that address different sub-topics) into different replies, or better different new threads, with a proper new "procedure name" (aka topic subject).

But the forum doesn't have codetools for navigation. So I fear we need one really large block. But within that, the text can go spaghetti by having any amount of forward and backward references.

[eny]

Our new best friend says:

A procedure/function should ideally:

• Do one thing
• Have a clear name
• Be short enough to understand quickly

There’s no strict limit, but many developers try to keep functions roughly 5–30 lines.
For reasons of:

• Understandability
• Debuggability
• Reusability
• Testability
• Maintainability

Q.E.D. (Must be; AI says so )

[valdir.marcos]

Our new best friend says:

A procedure/function should ideally:

• Do one thing
• Have a clear name
• Be short enough to understand quickly

There’s no strict limit, but many developers try to keep functions roughly 5–30 lines.
For reasons of:

• Understandability
• Debuggability
• Reusability
• Testability
• Maintainability

Q.E.D. (Must be; AI says so )

[Ten_Mile_Hike]

"The interesting part is that claims that a function/procedure is too long are relatively often made but, what is extremely rare, actually non-existent so far, are a solid set of reasons that justify the claim."

Code: Text  [Select][+][-]

1. As with a famous court decision in the U.S. regarding pornography noted: " We may not be able to define it, but we know it when we see it."  :D :D :D

[440bx]

Leave it to lawyers to reach such "bright" conclusions...  good thing scientists and mathematicians know better.

[Martin_fr]

"The interesting part is that claims that a function/procedure is too long are relatively often made but, what is extremely rare, actually non-existent so far, are a solid set of reasons that justify the claim."

Well, "too long" may mostly be a subjective matter. Albeit, give a certain range there seem to be many people who share the experience of preferring smaller potions. (Though that is from my personal experience and feedback I have received from those I know, it seems that a few other posters here might back that feedback, but not all).
And even the most critic of this division wrote that he observed a "majority" (his word) writing the code in functions to divide it up. If that majority would suffer from doing so, that would be odd....

But then there also most likely is a person (or  a few) that will be able to read and understand a single 50000 line function and find it easier than reading the same code when it is divided into functions, never mind by which criteria and/or with which resulting size that division is made.

Comfort for the human brain is not defined that much by static criteria that equal for all. Comfort is what you are used to and trained for. Look at people solving rubik cubes. Blind and in seconds. Memorizing the mixed up pattern before being blind folded. It would seem impossible. But it isn't.

And there lies the problem in finding more than at best a statistic of subjective views. If you take a 1000 people, how to you make sure there pre-comforting (the training they may have inadvertently had by past experiences) is within the same distribution as would naturally occur. You could maybe measure that on a group of 1000 people who are absolute newbies, and never programmed before the study.
But how to find out what a seasoned programmer should prefer by nature, when he already has been nurtured?

Maybe you could find a 2 groups of a 1000, one used to one style the other to the other. And then measure how long until they become comfortable with adapting to the opposite of what they currently do. I wonder if such a study has been done in a credible manner. (and if I do not overlook some fault in the setup)

[simone]

The topic of functional decomposition is a classic in software engineering textbooks. Among the many I've read over the decades, the famous book "Clean Code" by Robert Martin comes to mind. Here, on page 34, the author states the following:

"The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify. I can’t provide any references to research that shows that very small functions are better. What I can tell you is that for nearly four decades I have written functions of all different sizes. I’ve written several nasty 3,000-line abominations. I’ve written scads of functions in the 100 to 300 line range. And I’ve written functions that were 20 to 30 lines long. What this experience has taught me, through long trial and error, is that functions should be very small (... omitted...) Functions should not be 100 lines long. Functions should hardly ever be 20 lines long. "

[440bx]

There have been scientific studies that have proved that the human brain is significantly more capable of managing linear relationships than _any_ other type of relationship.

Sequential is easiest to understand. 

The moment linear sequences are broken into pieces they are no longer sequential because it cannot be known just by looking at the pieces what sequence they belong in.

It makes sense to want to create groups that implement atomic tasks but, that does NOT mean the whole needs to be broken into pieces.  That's the _fallacy_ way too many programmers have bought into, continue buying into and regrettably seem unable to overcome.

Groups can be created within a linear sequence.  Unfortunately that is not a commonly seen feature in compilers (though the "inline variables" feature is an atrophied attempt at creating such groups.)


As previously mentioned, some case statements go on for hundreds, many maybe even thousands of lines and, breaking each case into separate functions would be very _detrimental_ to clarity and maintainability.


The longest function I've ever written exceeded 27,000 lines.  It was a case statement.  Breaking each case into a separate function would have converted a very easy to follow and understand program into a jigsaw puzzle (it would have been completely absurd to do that.)

[Martin_fr]

There have been scientific studies that have proved that the human brain is significantly more capable of managing linear relationships than _any_ other type of relationship.

Sequential is easiest to understand. 

Then my brain appears to me non human. And I brought friends with me (from where ever we came, I don't remember)...

As I said, human brains have overcome page turning in books. Which according to how you preset your argument makes books really hard to understand, and we should still have scrolls...

Jump to declaration is to me way less an effort than turning a page in a book. The computer does it for me. I just continue reading.

What does break the sequence in the code is every single loop, and every conditional. But that dose not get worse by creating functions. In fact the containment makes it easier, because their bounds now must be within each function making the search for the non sequential upper bound so much easier.

But I am repeating myself, and you ignored that already. So I guess its pointless. Especially since now that I repeated it, it isnt sequelized anymore.


But to add something I haven't said.

Taking unrelated sub tasks into their own functions => improves the sequentiality of the actual related parts that are the remaining code. When I now read that code, I only need to read one function call. That is the same than your proposed comment. But it saves me from having to skip (jump / non sequel) over the code that was explained by the comment.

So according to your statement: using functions makes code easier to read

Yes, I did see: you use code folding instead => for me that is extra work, having to open or close fold (depending on what they currently are).
Also, if you ever have any of them folded then that conflicts with you earlier statement that you never trust the function-name (or comment) but that you always read the entire code to check the implementation (something I only do, if I don't know the code yet, because once I have done it, I do trust myself)

The moment linear sequences are broken into pieces they are no longer sequential because it cannot be known just by looking at the pieces what sequence they belong in.

Have you ever tried to follow a recipe to cook something. Imagine if it read like this

Take 3 grams of sugar. To measure 3 grams of sugar get your scales and a container. Measure the weight of the empty container. .....

Must be real fun to follow that recipe. But it is strictly sequel.... So perfect for you.

The longest function I've ever written exceeded 27,000 lines.  It was a case statement.  Breaking each case into a separate function would have converted a very easy to follow and understand program into a jigsaw puzzle (it would have been completely absurd to do that.)

And when you read it, all of it, entirely without skipping anything... I assume you do speed reading so it didn't take to long....
But when you reached around line 26900, did you still recall the exact content of every earlier line you read?

I don't know that code, and it may have good reasons (or not) to stay together. That is not the point. But it does not act as an argument that other code should never be divided appropriately into functions. That is of course unless you indeed can recall all 27000 lines after reading them.



You yourself say "certain atomic tasks"... Though earlier examples of yours show that you rejected the idea for some task that by their description would each be atomic.... But maybe those description were misleading...
 
In any case: please remember I never suggested, not even hinted, that size is used as reason to split something. I always have said that creating function is purely done by code having a distinguishable, clearly defined, and different from the rest,  task.

The mention of size that I made was that in my experience by doing so, bigger functions (like 1000 lines) become rare. They still exist, but very rare. Size is not the cause. Size is merely a side effect.

I am just stating that, because the way you present your "arguments" does leave some uncertainty if you take this into account. Maybe you do, maybe not... Can't tell.

[Martin_fr]

There have been scientific studies that have proved that the human brain is significantly more capable of managing linear relationships than _any_ other type of relationship.

Also your statement leaves unclear how the subjects were selected, and if the result is the default, or the limit.

See the rubik cube stuff and other similar things. The human train can be trained to very specific tasks, and those tasks can be quite complex. Therefore a human brain trained for something will be much better at that task, than at other tasks. Even if before the training it would have been better at the other.

Dose the study prove, that no human brain can be trained to be better at following a reasoning that is presented with pagination (and function are not different from pagination, in an IDE with navigation).

----
It may well be, that for an absolute beginner the purely one function may be easier to read. But for someone who has an innate skill for programming and training this may be the opposite.