How many lines is too many lines ?

[440bx]

In one case, I remember the subjects were university students because the study was done by the university.

The Rubik's cube example is very poor.  The percentage of people who can easily solve it without being trained to solve it is very small.  It should be noted that anyone, with an I.Q close to 100 or better, can be trained to solve it no matter the initial state (provided the initial state is possible.)

The studies (there is more than one) were general and the conclusion is invariant.  Human brains can understand sequential relationships easier than _any_ other relationships.

That's why in the progression 1, 2, 3, 4, 5, ?, what ? is, is obvious to just about everyone. Whereas, in 2, 4, 12, 48, ?, it will take the average person a few seconds to figure out what ? is. 

Be honest, for you, wasn't figuring out the first sequence easier and faster than the second one ?  It is for over 99%+ of human beings.  The reason ? simple! because the first is a linear sequence whereas the second one isn't.

It's the same thing with a jigsaw puzzle.  Just by looking a 50 individual pieces in random locations will NOT enable anyone to figure out what the complete picture is in a very short amount of time.  Something which is completely obvious once the puzzle is assembled (it's instantaneous then.)

It's exactly the same thing in programming.

Having 50 functions somewhere in the code provides NO information whatsoever as to what purpose their "assembly" fulfills (there isn't even an indication that they go together - individual functions don't even do that much!.) 

When the code is _not_ broken into pieces, _once the programmer has read all the code in the function_, odds are reasonably good the programmer has at least an idea of what task it performs.  This is NOT the case when the 50 separate functions have been read, because they may not even appear in the sequence they are executed (or supposed to be executed.)  The only way to figure out what those things do, is reading the function that puts them together (in a linear sequence) and then the programmer has to _remember_ what/how each separate function does its thing (which is something the great majority of people will be unable to do (the card flipping game proves that.))

The difficulty of logically assembling little pieces that are scattered around increases geometrically as the depth of the breakage increases.  IOW, a function broken into multiple functions which in turn are also broken into multiple function which in turn are also broken into multiple functions which in turn.... (rinse and repeat)

As a side note (side effect), it also complicates error handling which is why exceptions are so "popular" (abused) now.  The programmers paint themselves into a deeply nested corner and need a mechanism to get out of the 10,000 leagues of binary junk they've sunk themselves into.   

[Lauriet]

I know I said I surrender, but you just don't get it.

if I write:

if ItIsRaining then
  TakeUmbrella
else
  PutShortsOn;

Know, why do you think that you need to search through the listing for the 3 procedure/functions to read them.
Only if you want to change them do you need to look at them. This is what abstraction is all about.
50 years of programming/learning has come to this conclusion, but it seems you are the only one on the planet
that realises that we have all been tricked.

[440bx]

Know, why do you think that you need to search through the listing for the 3 procedure/functions to read them.

Because, at the very least, the programmer has to ascertain that "TakeUmbrella" actually fetches the umbrella instead of washing socks.

Aside from that, the programmer should, at the very least, be familiar with the code instead of making assumptions and making changes without a clue as to what may or may not be affected.

What's next ?... don't read the source code ??? is that really what programming has become ?  Read the source code = too much work ?  is that it ?

[Lauriet]

Well, if you have written the program YOU DO know what TakeUmbrella is, and who on gods green earth would name a procedure washsocks if its action was to take an umbrella. Now you are just nitpicking.
Clear you think its OK to write procedures 1000+ lines long, so I don't know why you asked the question. Why did you ask the question ?????

[440bx]

Yes, if you wrote the program then hopefully you know what the function/procedure does but, if the program you wrote is being maintained by someone else, that person should _never_ simply assume that the function is well named simply because what _you_ consider is a good name may not be what someone else considers to be an appropriate name.

In addition to that, as time goes by and code is maintained/modified, what may at one time have been a good name doesn't necessarily reflect what the modified code does or the way it does it (if at all.)

I asked the question because I wanted to see if someone had a _solid_ set of premises on which to base their opinion and, so far, I have not seen any.

Just small/short because some people have simply proclaimed that small/short is better.  Not particularly convincing.

[Martin_fr]

Well, you are obviously set out with the aim to deny - never mind what.

Good bye.

[Martin_fr]

I am still not convinced your study applies. Your examples seem poorer than you claim mine to be... But no point for me to explain.

[Martin_fr]

I know you are going to misinterpret it, but

If I have a cards with numbers from 1 to 5 (and want you to guess ? as the next), and I show them to you so you do get to see them in order => does it matter if have them in the same order before showing? Because the editor shows me the code in the order I need. Never mind were it is. The sequence does not depend on that. But I expect you will find a way to misunderstand that (again). Statistics of your past reply suggest that)

[440bx]

if you have individual functions (your cards) the only sequence that matters is the one they are called in and that's completely unknown until you read the function(s) that calls them.

This means that, at least in Pascal, if you simply read the functions as they appear in the source, the information you get is of very little value simply because you are looking at pieces instead of the whole.  There is no way around that no matter how you try to slice it.  In addition to that, there is plenty of code out there where the sequence in which the functions appear is completely different than the sequence in which they are called.  Basically, reading the source is of very limited value _until_ you reach the function/procedure where they are used which is where you find out the sequence in which they are used.

You are simply claiming that looking at the scattered pieces of a jigsaw puzzle is easier to understand than the assembled puzzle.

[Xenno]

I tend to write large subroutines, using comments and begin-end blocks to define distinct sections. In my experience, subroutines should be stack-aware and debugger-friendly; navigating a deep call stack can often be frustrating. I generally only extract a section into a separate procedure when it needs to be shared with other parts of the code.

Regarding the thread subject, I’ve never seen the compiler error related to a large procedure. Maybe I haven't written large enough ones, but I don't believe the compiler treats long procedures as an error, a warning, or even a note. One possibility for a limit would be the optimizer's node limit.

[Martin_fr]

I see what you are doing... You are throwing me another "claim", semi compelling, but easily defensible... Leads me to believe the goal is not discussing the item (that had been done to full extend, so it can't be). Then the goal must be to simple but oil into the fire and drag the discussion further.

Fun fact, want to know how I got to that conclusion? It was the next possibility in line (sequence).

[440bx]

navigating a deep call stack can often be frustrating. I generally only extract a section into a separate procedure when it needs to be shared with other parts of the code.

THAT is a reason to create a function/procedure, not some mostly baseless opinion about "functions should be small/short".

Additionally, deep call stacks create a lot more problems than just frustration.

[jamie]

if you want to save some stack operations, you could always just do a direct jump in the middle of some function elsewhere and maybe even have that one do another jump before it finally returns.

Seen it, done it. 

btw, never enough lines!
Jamie

[Martin_fr]

not some mostly baseless opinion about "functions should be small/short".

In all the parts I added I have never advertised that. In fact I have clearly stated that this is NOT cause.  It merely happens to be side effect.

You are simply claiming that looking at the scattered pieces of a jigsaw puzzle is easier to understand than the assembled puzzle.

Well, its quite different. In a whole program, you have many pictures that each would be a puzzle.

But just to make the point, I have solved puzzles, I have seen others, I even found some online videos about completive puzzle solving.

No one, not ONE SINGLE person in all of this solved the puzzle from top, left, going each row from left to right. And if your "in sequence" was so true, then that would have to be how it is done.

[440bx]

No one, not ONE SINGLE person in all of this solved the puzzle from top, left, going each row from left to right. And if your "in sequence" was so true, then that would have to be how it is done.

hmmm... just guessing... that might be because a program isn't a geometric shape. 

That said, it can be and, unfortunately too often is, broken into tiny pieces just because it has been baselessly proclaimed by some that "functions should be short/small".