How many lines is too many lines ?

[Martin_fr]

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".

Well, yes, there likely are some people who do it for that reason...

But, that doesn't affect the points I made. I never said to do that.

[LeP]

You see, I compare this discussion to the discussion about what is beautiful and whether beautiful is X or Y.
It's universally known that "beautiful" is subjective, but it's equally universally known that anyone who observes something beautiful recognizes it without any rules.

The same goes for code; writing code is a subjective practice. But anyone who sees well-written code recognizes it... without any rules, whether long or short.
There will never be a rule that dictates whether code should be long or short, but I think we will all be able to recognize when it is written well.

[440bx]

The same goes for code; writing code is a subjective practice.

No, if that were true then all-out spaghetti code would be acceptable (since code structure is, presumably, subjective.)


Here is a _rule_: with one exception, a function or procedure is too short when it does _not_ fully implement a logical task.  That rule alone can determine and justify how many lines of code a function/procedure should be (which of course, varies depending on the task being implemented.)

I won't mention the one exception (yet) because I think it should be easy to figure out what it is.

[Lauriet]

You keep saying 'baseless claims'
Do you really dismiss 50 years of research, development, academic opinions, practical experience, language development as baseless claims ???
Every time someone makes a good point, you dismiss it.

OK, now its your turn.
Please give us a few references from anyone in the computer programming field that advocate for NOT breaking programs into manageable pieces.

I suppose you don't use units in your programs, cause they come with function/procedures, and you will have to read all the unit code to check it.
Do you read all of the FPC code cause you don't know if its and umbrella or a sock ?
Do you read the assembler to make sure its correct ?
Do you chop up the processor core to make sure its wired correctly ?

Time to put you reputation were your mouth is.
Post your code here, and we will see how well written it is.
If I don't see your 1000+ line procedure posted, we will all know you don't have the courage of your conviction.

[440bx]

You keep saying 'baseless claims'

And I stand by that.

Do you really dismiss 50 years of research, development, academic opinions, practical experience, language development as baseless claims ???
Every time someone makes a good point, you dismiss it.

That's a good example of a baseless claim.  Where is any of the research you are alluding to ?  Just because someone proclaims one thing to be one way or another doesn't make it that way.  If you believe that then the Bible says that everything rotates around Earth, are we supposed to believe that because billions of people read that book ?  Do you believe earth is 6000 years old ?... my point is: there are claims for everything and just about anything out there and a great number of them are totally baseless (e.g, as in the Bible... I'm using the Bible as an example of how misguided and empty your argument is but, to be clear, it is just a handy example, it is not my intention to start a religious argument of any kind.)

OK, now its your turn.

I provided an example of how a linear structure is easier to understand than a non-linear one.  Are you suggesting that's not the case ?   1, 2, 3, 4, ?  guess what ? should be.  Look for the other sequence I provided  which is non-linear  and tell me which one is easier to understand.

Please give us a few references from anyone in the computer programming field that advocate for NOT breaking programs into manageable pieces.

There are a number of program complexity measures that will _claim_ a program is less maintainable as the number of pieces the program is made of increases and as the call depth increases.  Note that I wrote _claim_ because while the assertion is reasonable, none of the systems that measure complexity seem to have been subjected to thorough scientific study.

I suppose you don't use units in your programs, cause they come with function/procedures, and you will have to read all the unit code to check it.

Of course I use units, a unit is just a bag of code.  IOW, you don't call a unit.  It makes sense to group functionally related code into a unit.  That does not in any way affect the linearity of the code unlike functions and procedures.

Do you read all of the FPC code cause you don't know if its and umbrella or a sock ?
Do you read the assembler to make sure its correct ?
Do you chop up the processor core to make sure its wired correctly ?

1. I read _all_ the code in my programs and _all_ the code in programs I maintain and, almost always in libraries I use.  As far as FPC, I've read some of the code but, I sort of trust that the compiler simply works (which unfortunately isn't always the case but... I will only read _all_ the relevant code if/when I ever decide to make changes to it.)  That's one of the many reasons I don't use .net and I don't use the Lazarus/Delphi "form designers", I have no desire to read all that code, I don't think it's good code and lastly, while it gives the programmer a headstart, inevitably those frameworks get in the way, they are programming straight jackets.

2. I do read the assembler, every time! I do that while developing the program (I've asked, countless times, for a better disassembler in Lazarus... you can find the posts, if you'd like to check the claim.)  Not only that, once I consider the program done, I fully disassemble it, usually using IDA pro, to see the _entire_ program including what the compiler has done.  Guess what ?  IMO, every programmer should do that.  It is not uncommon that reviewing the disassembly prompts me to make changes in the program because I didn't like the compiler's generated code.    That's how you find out the _atrocious_ code the "= ();" initialization for records generates.  That's just one example that comes to mind, by far not the only one (unfortunately.)

3. No. it isn't my job to design the processor therefore I have no reason to chop it up.  That said, I think a programmer should know the processor architecture which, for an intel processor, means having read _all_ of the intel manuals about the processor (to be honest I'm behind in that one... it's been a few years since I've done that.)

Time to put you reputation were your mouth is.
Post your code here, and we will see how well written it is.

1. No problem.
2. No problem either.  I suggest you look at ZydisInfoC which is posted here in the forums.  I don't recommend ZydisInfoA because that one is a port of the original C code.  IOW, it isn't structured the way I would structure it but ZydisInfoC is very close to how I would structure a production quality program.

If I don't see your 1000+ line procedure posted, we will all know you don't have the courage of your conviction.

Check out ZydisInfoC.

You'll find 1000+ line functions/procedures there.  Impress me... change the code then show how your jigsaw puzzle is easier to maintain and understand than my code.  Show in code that your claims have a semblance of validity.

[Lauriet]

Please provide a link for DisInfoC.
A google search comes back blank.

[440bx]

Please provide a link for DisInfoC.
A google search comes back blank.

The thread that explains everything about ZyDis is found at:
https://forum.lazarus.freepascal.org/index.php/topic,67665.msg521432.html#msg521432

The ZydisE.7z archive attached to that post has ZydisInfoC as well as all other Zydis examples.

A description and screenshot of ZydisInfoC is found in the post:
https://forum.lazarus.freepascal.org/index.php/topic,67665.msg521439.html#msg521439

If you want to compile and run the examples, follow the instructions in the first post.  if you only want to look at source code the ZydisE.7z archive has everything you want.

HTH.

ETA:

Corrected the first link (it was the same as the second link.)

[Lauriet]

Yep the proc' i found was way too long.
As I guessed, you had to use lots of comments to explain the code......this is one reason to split it up
and use descriptive names. Also you have used lots of 'break', 'continue', 'exit' etc. This is just another way to use 'goto'. If you need them, then you should restructure the code. You should educate your self on the idea of 'one entry point and one exit point.'

You don't need to keep declaring a const/type/var blocks. Once is enough.
There seems to be some 'magic numbers' in there. How would anyone know what  they mean.....use a constant.

    if IsFunctionPrologue() then
    begin
      PrologueFound := TRUE;

      break;
    end; { if function prologue ... }


This is just one example of atrocious code.
Why do you even need the break ???
Why do you need the comment after end ???

It should read:

  ProloguFound := IsFunctionPrologue;

[440bx]

Yep the proc' i found was way too long.

Since you mentioned IsFunctionPrologue(), I presume you're referring to AnalyzePe32().

It isn't too long.  Moreover, it has a number of nested functions which exist because their code is executed in more than one place (as should be the reason for a function and/or procedure to exist.)

As I guessed, you had to use lots of comments to explain the code......

Yes, I consider comments that thoroughly explains what the code does to be a characteristic of good programming but, feel free to disagree.

this is one reason to split it up

No, that's no reason to split it up.  Splitting that function would remove the surrounding context in which the code is being executed which would be detrimental to clarity and ease of understanding.

and use descriptive names.

I believe I use very descriptive names and also very descriptive comments.  Do you have something against that ?  In addition to that, what makes you think that a usually short function name is better than a descriptive comment ?... Please explain what the problem is with having a lot of comments.

Also you have used lots of 'break', 'continue', 'exit' etc. This is just another way to use 'goto'.

Yes, I freely use break, continue and exit.  That's WAY different than a "goto" and since you apparently don't know what the difference is, here it is: a "goto" can go just about anywhere, IOW, there is no indication of the goto's target in the "goto" statement itself (the presence of a label is worthless because the label can be anywhere), a break, continue or exit's target is determined before the statement is found, e.g, the target of a break is the end of loop and hopefully you read the source code and know where the "while", "for" or "repeat" started, also, unlike in the case of a "goto", it really shouldn't take much effort to find the end of the "while", "repeat", "exit" target.   IOW, while break, continue and exit are control flow instruction they ARE very different than a "goto" in a _crucial_ way, their target, unlike a goto, is preset by the location in which it occurs.  Free education for you.. you're welcome.

You should educate your self on the idea of 'one entry point and one exit point.'

I'm very pleased you bring up education... you obviously need some since you can't even tell the difference between using "goto" and using "break", "continue" and "exit". (however, if you read the previous paragraph, you should be able to now. Again, you're welcome.)

You don't need to keep declaring a const/type/var blocks. Once is enough.

No, it's not.  There should be one block for every group of logically related variables, types and constants.  That's what justifies multiple block declarations.  No spaghetti variables, types nor constants.  Keep things that are independent separate from each other and, group things that are related. 

There seems to be some 'magic numbers' in there. How would anyone know what  they mean.....use a constant.

I don't like magic numbers anymore than you do.  Please show the instances where non-obvious and _uncommented_ use of numbers appear.  Thank you.

    if IsFunctionPrologue() then
    begin
      PrologueFound := TRUE;

      break;
    end; { if function prologue ... }

This is just one example of atrocious code.
Why do you even need the break ???
Why do you need the comment after end ???

if you had read the code, you'd know the break statement is to exit the while loop.  What's atrocious is that you can't figure that out.
I'll give you that the comment is superfluous since it is quite obvious what the "end;" is for.

It should read:

  ProloguFound := IsFunctionPrologue;

No, it should not because that doesn't cause the remainder of the while loop to be skipped if the prologue was found. 

My recommendation to you is: read the code, if you do, it will be more likely for you to find something that can genuinely be improved (like your observation about the superfluous comment... good catch!)

The one observation you should have made is that the "if not PrologueFound then" which follows the first "if" is superfluous because that statement can only be reached if the prologue has not been found.  That test was probably there as a result of code that originally needed it and I later changed and not noticed that the "if" became obsolete.  You should have caught that. 

Ok, I see you are quite talented when it comes to generating poor suggestions BUT, I'll give you a chance to prove me wrong. Rewrite AnalyzePe32() in the way you believe it should be coded.  IOW, restructure my code to fit what you think is right.  Note that I'll test whatever you come up with, it has to be as good and thorough as the original code otherwise it will just be junk.  Just in case, it has to be as functional as my code, IOW, successfully cover all the test cases.   At least you have my code to guide you... I didn't have that.

Show me what you got...

[Lauriet]

Like I said,
If I had to work on procedures that big, I would quit my job.

If I though you would change your mind I would attempt it, but after reading some of your other posts, I'm convinced that you are too insecure about your programming to take any suggestions onboard.

You asked the question initially, "How many lines is too many lines" presumably you were open to opinions, but clearly you are not.
All you have done is to dismiss and argue with some good people that could help you.

I really am perplexed why you asked the question. Do you only want people to say "Yes its OK"

Instead of taking onboard 'one entry point, one exit point' you flip that to a juvenile barb.
Well, what have you studied about this topic?
What is the advantage of this structure?
Who originally described it?
What was they motivation for it?
There are many books, academic papers, source code examples that demonstrate the advantages of this principle.

Now I know you are going to reply with another defensive tirade claiming you are right and everyone else is wrong. You clearly are insecure about your programming style and do not want to learn anything about the topic.

WTF: you put a break in that place !!! Nickalaus Wirth would roll over in his grave.

As they say don't argue with idiots, they only bring you down to their level.

[440bx]

You asked the question initially, "How many lines is too many lines" presumably you were open to opinions, but clearly you are not.

I want opinions that are well founded, not just empty claims, much less a bunch of pathetic dribble.

[Martin_fr]

You asked the question initially, "How many lines is too many lines" presumably you were open to opinions, but clearly you are not.

I want opinions that are well founded, not just empty claims, much less a bunch of pathetic dribble.

Yes, your pattern is clear. You don't do any research, you don't put any work in it.
You send others to do lots of works, dismiss it and ask them to do even more work. Wich you will disregard again.

Why I say that?
- A lot of your question have been answered. But you ignored them.
- You reverted on some of your own statements, when you apparently wanted to trigger more answers.

No, I will not link to the occurrences. That would mean to actually fall for your trickery by me doing more work for you, without any difference made by the result.

Good luck.

[cdbc]

Hi
@Martin_fr: +1
Regards Benny

[Thaddy]

As long as there are sufficiently enough setjumps, longjumps, breaks, continues, exits, gotos and labels even very long routines should be very easy to understand  You do not need procedures or functions.

[cdbc]

Hi Thaddy
Hahaha -- I want some of that weed, you're smokin' 
...or is it the meds, kicking in?
Regards Benny