Posts: 597
Threads: 110
Joined: Apr 2022
Reputation:
34
Long and/or complex programs, I make heavy use of GOSUB. To make stuff easier to find, I create labels that have both descriptive text and index numbers.
Like "a100_DoWhatever"
For example:
Posts: 2,169
Threads: 222
Joined: Apr 2022
Reputation:
103
08-10-2024, 02:55 PM
(This post was last modified: 08-11-2024, 06:43 PM by Pete.)
Code: (Select All) IF Left$(user$,5) = "Steve" Then
...do stuff
GOTO end_check
END IF
IF Left$(user$,4) = "Jack" Then
...do stuff
GOTO end_check
END IF
IF Left$(user$,2) = "Jo" Then
...do stuff
GOTO end_check
END IF
...57 more unique cases to check and deal with...
end_check:
Instead of GOTO, I use a 'Faux Loop' for similar situations.
Code: (Select All)
DO ' Faux Loop.
IF Left$(user$,5) = "Steve" Then
...do stuff
GOSUB end_check
EXIT DO
END IF
IF Left$(user$,4) = "Jack" Then
...do stuff
GOSUB end_check
EXIT DO
END IF
IF Left$(user$,2) = "Jo" Then
...do stuff
GOSUB end_check
EXIT DO
END IF
...57 more unique cases to check and deal with...
LOOP
END
end_check:
PRINT "We're done here."
RETURN
So 60 extra 'EXIT DO' statements, but copy/paste makes that a snap.
This is more about style than optimization but I would have to ask myself, hmm 60 times, screw it, I'll use GOTO once in the code. I mean imagine if that WASN'T an option. That would suck. This it what I love about BASIC, little regulation and lots of options.
My dislike of using GOTO comes from my early Texas Instrument programming days when we needed to assign line numbers to every line of code. Change the line numbers when editing the code and it often blew up all the GOTO references, which then meticulously needed to be changed, as well. I'd also have to say GOTO statements were the #1 cause of spaghetti coding.
The few times I have used GOTO is in some very long routine where I want to circle back to something that just couldn't be done in a nested or recursive subroutine or if making my DO:LOOP nest meant many exits for parts of the routine that had nothing to do with what was coming down the pike. These types of situations put the spaghetti on the other foot!
-------------------
Like OldMoses, and I do like OldMoses, I also always use RESTORE and a label with all of my database calls. That really helps prevent database errors.
-------------------
JRace has a good point with combining math functions. I like the way doing that frees up space so I can see the next thing my code is doing, rather than jut all the calculations I know it needs to do. I just, again, wish we had a COLOR LABELS option in the IDE. That would be way cool! Right now I'm doing a colon search... oh wait, that doesn't sound good... to find my labels.
Pete
Shoot first and shoot people who ask questions, later.
Posts: 3,964
Threads: 176
Joined: Apr 2022
Reputation:
219
In the above sample code, why not Select Case... End Select or If... ElseIf... Else... End If and avoid false loops and all those If.. End If conditions? no jumping needed with goto's, find the case that works then move on.
b = b + ...
Posts: 2,696
Threads: 327
Joined: Apr 2022
Reputation:
217
(08-10-2024, 03:19 PM)bplus Wrote: In the above sample code, why not Select Case... End Select or If... ElseIf... Else... End If and avoid false loops and all those If.. End If conditions? no jumping needed with goto's, find the case that works then move on.
Because you're not checking against one single case. Make a select case to check for:
LEFT$(user$,5) = "Steve"
LEFT$(user$,4) = "Pete"
LEFT$(user$,2) = "Jo"
SELECT CASE... what?
And the problem with IF.. ELSEIF... is that I just personally don't use them a lot. They probably would work just fine, but they're just not my usual style.
Posts: 2,169
Threads: 222
Joined: Apr 2022
Reputation:
103
Right, because this thread is about style, and not so much code optimization.
I suppose another thing to mention about style is the importance of continuity. Go back 10+ years to look at some of your large older programs and I bet those who have continued with a same or very similar style have a much easier time of updating their code. This is why I think it is important that folks new to QB64 develop not only the best optimization skills, but the best style that suits them if they intend to stay with projects for many years.
Pete
Shoot first and shoot people who ask questions, later.
Posts: 1,002
Threads: 50
Joined: May 2022
Reputation:
27
Quote:Pete - My dislike of using GOTO comes from my early Texas Instrument programming days when we needed to assign line numbers to every line of code. Change the line numbers when editing the code and it often blew up all the GOTO references, which then meticulously needed to be changed, as well.
Was it numbered consecutively like this: 1 - 2 - 3 . . . instead of: 5 - 10 - 15 - . . .? In the MS GW-Basic manual it is recommended that it be done this way, with even wider spacing: 10 - 20 - 30 ...
This way, inserting further instructions into the program should not cause any problems. In any case, I did it as recommended.
If you want to experience the old days, there is a good emulator for GW-Basic under Win 10: PC-Basic 2.0 (GW-Basic)
Start pcbasicw.exe. Works great!
Posts: 2,169
Threads: 222
Joined: Apr 2022
Reputation:
103
I think you could choose your increments like 5, 10, 15 or 10, 20, 30, etc., but I remember being able to just write my own line numbers. The trick then was to go wide, maybe 10, 20, 30 or wider, 20, 40, 60, etc. so you could insert lines when editing the code. Program routines like REMLINE came along a little later to automatically change your line numbers and the calls to them. I made one of these and posted it several years ago at the QBasic Forum.
Pete
Shoot first and shoot people who ask questions, later.
Posts: 1,272
Threads: 119
Joined: Apr 2022
Reputation:
100
08-10-2024, 07:53 PM
(This post was last modified: 08-10-2024, 07:53 PM by TerryRitchie.)
(08-10-2024, 07:30 PM)Pete Wrote: I think you could choose your increments like 5, 10, 15 or 10, 20, 30, etc., but I remember being able to just write my own line numbers. The trick then was to go wide, maybe 10, 20, 30 or wider, 20, 40, 60, etc. so you could insert lines when editing the code. Program routines like REMLINE came along a little later to automatically change your line numbers and the calls to them. I made one of these and posted it several years ago at the QBasic Forum.
Pete A lot of the old BASIC versions (TRS-80, Apple, etc..) had a command called RENUM that allowed you to renumber an entire program or just a portion of them. I used it quite a bit back in those days to create more space between my line numbers. RENUM was even smart enough to change reference line numbers within the code too, like GOTO, GOSUB, and ON x statements.
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Posts: 2,696
Threads: 327
Joined: Apr 2022
Reputation:
217
(08-10-2024, 04:28 PM)Pete Wrote: Right, because this thread is about style, and not so much code optimization.
I suppose another thing to mention about style is the importance of continuity. Go back 10+ years to look at some of your large older programs and I bet those who have continued with a same or very similar style have a much easier time of updating their code. This is why I think it is important that folks new to QB64 develop not only the best optimization skills, but the best style that suits them if they intend to stay with projects for many years.
Pete
Aye. And I think as far as I'm personally concerned, I find the "IF...GOTO finish" approach preferable to "IF....ELSEIF.....ELSEIF...." approach just due to the way my brain tries to process information.
IF x = 1 THEN
... do stff
GOTO end_process
END IF
My mind reads that, processes it as one complete segment, and then is done with it. My brain narrow focuses here, and all I need worry about is that one, small fragment of code.
If x = 1 THEN
...stuff
ELSEIF x = 2 THEN
....stuff
ELSEIF x = 3 THEN
.... stuff
With the above, my brain sees those as all continuous control block. It wants to understand EVERYTHING that's going on inside, before moving on and attempting any changes to the overall structure.
I suppose to me, it's kinda the difference between short sentences in writing, and endless run-on paragraphs.
I woke up. I ate breakfast. I got dressed. I went shopping. I ate lunch. I died.
Compared to
I woke up and ate breakfast and got dressed and went shopping and ate lunch and died.
Independent, sequential thoughts, rather than needing to decipher one long continuous thought.
(Just to try and explain WHY my style is, as it is, for ME.)
Posts: 344
Threads: 24
Joined: Jul 2022
Reputation:
20
ALL ways are good for BASIC /QB64pe!
The goal is to write as soon as little code to get the result.
So it must help for the debug and maintenance sessions
Those following are my preferences coming up from my little experience in coding BASIC.
I love CamelCase, I love suffixes, I love Labels, I love SUB/Function, I love DEFxxx letter/s, I love CONST
I love Pascalkind of structure (first declarations then instructions both for main both for single code block), declaration on fly are left as last change. ( think for i% = 1 to 10 step 1.... stuff... next i%)
I love documentation (comments for variables and code blocks)
I try to be free of GOSUB / GOTO/ DEF Fn so I prefer SUB/Functions with many parameters or SHARED variables into it
I hate numline, I love labels when I need them
I hate large blocks of code, I prefer to have so many little blocks called via SUB/Function (extremly splitting of code)
Happy coding friends!
|