I keep seeing references to the idea of using GOTO in a program as not being "good" programming, and yet, I've never seen any actual explanation of why this is. To me, its just another command.
Is it because its not in "vogue", or is there an actual functional disadvantage to using GOTO? The classic example I can think of to using GOTO would be in a situation where one selects from a "menu", say, three choices. You simply branch to the selected routine, not coming back to the menu.
Thanks all, Dex
One reason would be confusion... it's always harder to read the code when a person is using GOTO.
..constantly. Always using IF... END IF and the like regardless of how much more lengthy it would be and always avoiding GOTOs is considered harmful.
Nathan posted a link to an article somewhere here: "GOTO Considered Harmful" Considered Harmful.
As you guys say this, it occurs to me, perhaps its because all my QB programs tend to be small utilities I write for myself, where a "goto" or two isn't so important. I've never really written anything very large, like a game or such.
Dex
I'll do a search for nathans post.
Well if there is an alternative to the GOTO I can't think of it because my programs always re-use the same code over and over with different variables changed... such as
Code:
SCREEN 12
SKILL = 1
BATTLE:
LINE (0,0)-(640,480),0,BF 'FASTER THAN CLS
EN% = INT(RND * 5)+1
IF EN% = 1 AND SKILL = 1 THEN ENEMY$ = "Snake"
IF EN% = 2 AND SKILL = 1 THEN ENEMY$ = "Rat"
'well, I could use CASE but I'm lazy right now
and then the other stuff inside the battle label could change throughout the game, it just is the variables so if there is a better way to do the GOTO then I'd like to hear it
(unless it's GOSUB and RETURN i fugured out those already)
-Nova
loops?
Every program can be converted to a program that has purely IF, GOTO, arrays, tests on those arrays, and settings those arrays..... or even a series of on/off command followed by wait inputs from the user, followed by on/off commands, etc....
Hey agamemnus; Love the Carl Sagan quote, are you familiar with his "other" great quote, in reference to the classic "Hollywood" position . . . "If we're the only ones out there, its a terrible waste of space . . ." in which he said, "Somebody had to be first, . . . why can't it be us?"
In fact, GOTO is not so bad. I still use it. The thing is that whenever you can avoid it, do it. QB has newer structured programming techniques that makes your code more readable and structured. If you can use DO:LOOP, WHILE:WEND, FOR:NEXT and flags, don't use GOTO. I have recently returned to my old code to finish things and tidy up the thing a little bit, and it was a pain in the as s to understand that code that I wrote 3 or 4 years ago, 'cause it made extensive use of GOTOs.
Once you get used to, you'll like modern (if they can be called so) program flow structures instead of GOTOs, which are a small plot of dust from the days of pure assembly and fortran.
Anyways, GOTOs are often useful if you wanna get more efficience. A nice GOTO to break a loop or a complex IF/ELSE/ELSEIF structure may be mandatory in games.
So use it, but responsiblely.
I had written a program a while ago to run some probability experiments. The program had 9 nested DO loops that required millions and millions of iterations to solve and I kept getting an error for "Out Of Stack Space". I figured out a very simple solution to the problem.
When a program exits a loop and goes to a SUB, it stores a RETURN adress in the stack, so it knows where to go back, then, when you RETURN to the main module, that return address is cleared from the stack.
In my case, after I went to the SUB, I wasn't returning to the main module, the program was just continuing on with a new loop. So the return adresses were just piling up in the stack until there was no more room.
How I solved the problem was to make all of my subs part of the main module, but I changed them so they were not real SUB's, but just labels. Then I changed all my GOSUB statements to GOTO statements. If you use GOTO, then no return adress is stored in the stack, so it eliminates the need for extra stack space. Since the program was not RETURNing to the main module, I didn't need the return addresses anyway.
Normally, on compilation, Qbasic estimates how much stack space it will need to run the program, and then it automatically CLEARs that amount of memory, that's why the CLEAR statement is optional. In the case of my program, it was impossible to determine in advance, how many times the program would be exiting any one of the 9 DO loops. The number of times would vary from run to run.
Everyone says that using GOTO is bad practice, but this is one instance where I did not see any other solution.
Hedgehog.