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?
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 ...
Quote from: NoCforMe on January 27, 2023, 04:07:25 PM
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.
Quote from: NoCforMe on January 27, 2023, 04:07:25 PM
Rules are nice; but rules are made to be broken
:thumbsup:
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
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
Quote from: daydreamer on January 27, 2023, 05:53:32 PM
Quote from: NoCforMe on January 27, 2023, 04:07:25 PM
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:
. . . .
[get string length]
[validate string]
[do something else with string]
. . . .
instead of
. . . .
CALL ProcessString
. . . .
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" :cool:
Quote from: jj2007 on January 27, 2023, 09:00:10 PM
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" :cool:
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.
Whatever you do, don't listen to anything Niklaus Wirth says!
Discussion at SOF (https://stackoverflow.com/questions/611304/how-many-lines-of-code-should-a-function-procedure-method-have):
QuoteBob 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
Quotea 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:
1613 WndProc
0854 SubRE
0811 FindBookmark
0633 CbTimer
0519 ReSaveFile
0463 Copy2Forum
0449 HelpOrAuto
0421 openlinkOld
0365 AssRunCheck
0335 AssRunDrag a source over the attached exe to get your own "ranking" ;-)
Quote from: jj2007 on January 27, 2023, 09:31:00 PM
Discussion at SOF (https://stackoverflow.com/questions/611304/how-many-lines-of-code-should-a-function-procedure-method-have):
QuoteBob 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
Quotea 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.
QuoteMore 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.
Quote from: jj2007 on January 27, 2023, 09:31:00 PM
Drag a source over the attached exe to get your own "ranking" ;-)
Tried, but this is what I got:
Works fine here on my current Win10 64.
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".
Version 2, with a MsgBox saying you didn't supply a file, and allowing for UPPERCASE PROC and ENDP :cool:
Sorry, JJ, gotta complain a bit here: what's with your "just drag a file over it" schtick? I find that a pain in the ass. I have to, what, extract your .exe to a folder, then drag my file over it? Why not just put in a file open dialog? or am I missing something here?
Worse, I had to extract it and move it onto my desktop. I hate doing that with throwaway stuff like this.
Anyhow, I did it and here's what I got:
1053 MainWindowProc
0508 WinMain
0310 CubbyProc
0283 BookmarkProc
0220 ViewExtraFile
0219 PrintTheFile
0219 FindTextDlgProc
0207 ParseHdrFtr
0164 ViewExtraProc
0160 GetNextINItoken
There are quite a few blank lines in there ...
OTOH, at the bottom end are these:
0008 ToLower
0007 IniSetExtraWinY
0007 IniSetExtraWinX
0007 CenterDim
0006 IniSetWindowY
0006 IniSetWindowX
0006 IniSetWindowW
0006 IniSetWindowH
0006 IniSetExtraWinW
0006 IniSetExtraWinH
Quote from: jj2007 on January 27, 2023, 09:31:00 PM
0335 AssRun
Sorry, I just gotta ask you about this one ...
Quote from: NoCforMe on January 27, 2023, 10:29:07 PMWhy not just put in a file open dialog?
Why waste my time with throwaway stuff like this; CL$() (https://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1011) is simpler.
QuoteAnyhow, I did it and here's what I got:
1053 MainWindowProc
0508 WinMain
0310 CubbyProc
0283 BookmarkProc
0220 ViewExtraFile
0219 PrintTheFile
0219 FindTextDlgProc
0207 ParseHdrFtr
0164 ViewExtraProc
0160 GetNextINItoken
Looks pretty close to my coding habits :biggrin:
QuoteThere are quite a few blank lines in there ...
I don't have blank lines in my code, so: sorry for not taking them into account (I do use space before and space after, though; RichMasm can do that).
QuoteOTOH, at the bottom end are these:
0008 ToLower
0007 IniSetExtraWinY
0007 IniSetExtraWinX
0007 CenterDim
0006 IniSetWindowY
0006 IniSetWindowX
0006 IniSetWindowW
0006 IniSetWindowH
0006 IniSetExtraWinW
0006 IniSetExtraWinH
Commonly called "candidates for inlining or macros" ;-)
> Sorry, I just gotta ask you about this one ...
Assemble & Run
There is something that this discussion is assuming that is clearly nonsense, the notion that you format code to EITHER one or the other style.
Most of us have seen old style mnemonic code stacked in a vertical line along with push/call notation and no indenting and while you can get it to work, readability is poor as the style is not able to handle complex high level code and you end up with a cluttered mess.
Win 32 and 64 bit code must use OS functions, the Windows API functions and these functions are NOT low level, they are generally high level code that is necessary to interact with the OS. ASM is capable of writing this hack API code in a clear and readable manner and this gets production up to speed rather than wasting development time on clutter.
Save time by distinguishing between hack OS code and the stuff that really matters, puire mnemonic algorithm code. Coding the world's fastest MessageBox() will go over like a gnat breaking wind where a genuinely fast pure mnemonic algorithm is useful and can improve the performance of a finished app.
Quote from: jj2007 on January 27, 2023, 10:57:34 PM
Quote from: NoCforMe on January 27, 2023, 10:29:07 PMWhy not just put in a file open dialog?
Why waste my time with throwaway stuff like this; CL$() (https://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1011) is simpler.
OK, fair enough, I guess. But how is one supposed to use your "drag a file over it" apps? I could only think of 3 ways: put your app on the desktop, put it in the same folder with the file you want to drag, or open 2 Explorer windows. All of which are a PITA to my way of working. How do you do it?
If someone posts li'l apps here, I like the ones where you can just open the .zip and double-click on the .exe and presto! it opens.
Quote from: NoCforMe on January 28, 2023, 07:04:08 AMHow do you do it?
I simply extract the exe to a folder where a source happens to reside, then I drag that asm file over the exe. Easy peasy.
C:\Users\[your name]\AppData\Roaming\Microsoft\Windows\SendTo\ is a fascinating location, too.
My current location for such stuff is E:\Programming stuff\Assembly language\sandbox.
Try the SendTo folder. You can place *.lnk files there, for example a link to OllyDbg. Then, with a right-click on any exe, you can launch Olly from Explorer's (or any other file manager's) context menu. I also have links to Timo's TLPEView64 there, plus several other utilities.
I prefer the drag and drop approach, copy a single exe file to a target directory or alternatively copy a source file to the directory that has the tool and its simply faster than a dialog box based tool.
Quote from: jj2007 on January 28, 2023, 08:36:07 AM
Try the SendTo folder. You can place *.lnk files there, for example a link to OllyDbg. Then, with a right-click on any exe, you can launch Olly from Explorer's (or any other file manager's) context menu. I also have links to Timo's TLPEView64 there, plus several other utilities.
Ah, another "magic" folder thoughtfully provided by the boys (and girls) in Redmond. I'll have to try that sometime.
Quote from: hutch-- on January 28, 2023, 09:55:42 AM
I prefer the drag and drop approach, copy a single exe file to a target directory or alternatively copy a source file to the directory that has the tool and its simply faster than a dialog box based tool.
Right. I have a two-pane file manager (FreeCommander (https://freecommander.com/en/summary/)), so in one pane I keep the tool(s), in the other pane the source folder, so that I can drag the source over the exe without actually moving any files.
Besides, with a simple
; OPT_Arg1 \Masm32\somesource.asm, my editor can be convinced to launch the newly built exe with a commandline argument. Much, much faster and more convenient than a file dialog.