How many work items in a Procedure ?

[Shintaro]

Hi,
A general Software engineering question.The answer is one that I will use moving forward when thinking of design.

Q: How many things should a procedure do before it is too many? Typically speaking. (Heuristic)

For example, validating a string.
Should one procedure:
- Get String length
- Check for valid chars
- Break apart the string

Or should I break them into a procedure each?
I was taught 1 job = 1 procedure/Function
But then thinking further, given that method above of thinking, will it end up in a spaghetti mess with lots of little functions if the code expands?

[NoCforMe]

Dunno if this helps, but I'd say it should depend on how the function (procedure) is used, as well as any mini-functions within it. If the whole thing is used as a single unit--measurement, validation, etc.--then keep it as a single unit. However, if measurement, validation, etc., are used separately in other places in the code, then you might want to break them out as separate functions.

Also, if the thing is only used once, then maybe it should be coded in-line rather than made a separate procedure, with its call overhead and bookkeeping headaches.

Rules are nice; but rules are made to be broken ...

[Shintaro]

Dunno if this helps, but I'd say it should depend on how the function (procedure) is used, as well as any mini-functions within it. If the whole thing is used as a single unit--measurement, validation, etc.--then keep it as a single unit. However, if measurement, validation, etc., are used separately in other places in the code, then you might want to break them out as separate functions.

Also, if the thing is only used once, then maybe it should be coded in-line rather than made a separate procedure, with its call overhead and bookkeeping headaches.

Rules are nice; but rules are made to be broken ...

Cheers, Good points, thank you.
When to break the rules is the difficult part.

[daydreamer]

Rules are nice; but rules are made to be broken

Especially coding asm there is no Learning c recommend of proc use local variables
By inline code you mean use macros?
Or choose oop programming superclass/subclass if you prefer that, check biteriders subforum

[hutch--]

The simple solution is don't be rules based.

> Get String length - simple algo
> Check for valid chars - standard lookup table
- Break apart the string - parsing to a preset collection of definitions

[NoCforMe]

Rules are nice; but rules are made to be broken

By inline code you mean use macros?

No, silly, I mean in line with code instead of being called as a function:

Code: [Select]

. . . .
[get string length]
[validate string]
[do something else with string]
. . . .

instead of

Code: [Select]

. . . .
CALL ProcessString
. . . .


[jj2007]

I checked with two of my sources: 70,000 lines/424 procs=166 lines per proc. Now that is clearly too many, but it may serve as a rough indication what may still work. Aim at 50 lines per proc, and you should be ok. See it the other way: if I had aimed at "no more than 20 lines", I would have to manage 3,500 procedures in that code. The rule might be "what you can manage best"

[Shintaro]

I checked with two of my sources: 70,000 lines/424 procs=166 lines per proc. Now that is clearly too many, but it may serve as a rough indication what may still work. Aim at 50 lines per proc, and you should be ok. See it the other way: if I had aimed at "no more than 20 lines", I would have to manage 3,500 procedures in that code. The rule might be "what you can manage best"

I have never written that amount of code, so I simply don't know.
Putting it like that there is an obvious scalability problem and would have ended in crazy unmanageable project(s).



And that is the problem, most lecturers in University have never written sizable projects. They just parrot whatever is written in textbooks.
Seriously, I often wonder why I even bothered with University back in the 1990s.


Thanks mate, I appreciate it.

[NoCforMe]

Whatever you do, don't listen to anything Niklaus Wirth says!

[jj2007]

Discussion at SOF:

Bob Martin also says to keep it around 10. Personally I usually try to shoot for 10. If it starts getting close to 20, that's a mental flag to pay closer attention to that method

a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100-200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines.

P.S., the first ten of my editor's source:

Code: [Select]

1613 WndProc
0854 SubRE
0811 FindBookmark
0633 CbTimer
0519 ReSaveFile
0463 Copy2Forum
0449 HelpOrAuto
0421 openlinkOld
0365 AssRunCheck
0335 AssRun
Drag a source over the attached exe to get your own "ranking" ;-)

[Shintaro]

Discussion at SOF:

Bob Martin also says to keep it around 10. Personally I usually try to shoot for 10. If it starts getting close to 20, that's a mental flag to pay closer attention to that method

a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100-200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines.

Yes, good points.
This is interesting as well.

More than one level of indention in a method (indicates too many logic branches to only be doing one thing)

Which would drive up complexity and reduce readability.
Especially for the poor schmuck that comes along later trying to read the code.

[NoCforMe]

Drag a source over the attached exe to get your own "ranking" ;-)

Tried, but this is what I got:

[hutch--]

Works fine here on my current Win10 64.

[NoCforMe]

Delving into the philosophical side of this a bit, I guess I can kinda sorta agree to the "should only do 1 thing" argument.

Except: sometimes I write routines* that do basically one thing but with interesting and useful side effects. Which I argue can sometimes be more efficiently done inside that routine than elsewhere, especially in assembly language, where we like to take advantage of things like pointers in certain registers that are lined up ready to go, rather than having to reinitialize them somewhere else. And I actually kind of like breaking the rules like that--if it's manageable, not a tangle of snakes, and understandable.

That last, understandable: how about a rule that you need to look at any code you wrote a week or a month later and see if you can easily figure out just what frack you were doing. If not, rewrite it.

* Routines, functions, procedures: pick your favorite $5 word to describe "a bunch of code that does something".

[jj2007]

Version 2, with a MsgBox saying you didn't supply a file, and allowing for UPPERCASE PROC and ENDP