That looks surprisingly usable actually...
If you're a hardcore BASIC user, yes. Otherwise, if you're sane, no. As in, Oh hell no.
That looks surprisingly usable actually...
If you're a hardcore BASIC user, yes. Otherwise, if you're sane, no. As in, Oh hell no.
Adding a quick goto must have been much easier for those people than listing a bit of code, guess some line number range thats free and will not be needed soon, editing all line numbers and hitting enter to copy them, listing it again, typing in the line numbers alone to delete the original, still remember all numbers and list the next bit cause the screen was too small, ...
And later they would have dicovered they moved the code to a place where they need the linenumbers now for new code and repeat it all again.
... or just add a quick goto at that point?
That depends on the language -- error cleanup based around goto is idiomatic in C, but in most modern languages the idiomatic thing to do is to use throw instead.
Any instructor who says "NEVER" use GOTO may never have done much serious programming (where they are very useful for abnormal exiting of complex subroutines, and the horrors of number goto labels are long gone)
I'd probably still teach a class to never use goto, but then also teach that C error cleanup idiom as being the exception to this rule, and as a look inside how exceptional stack unwinding might be implemented in C++
10 REM early bit of code
20 GOSUB 40
30 GOTO 60
40 REM stuff they later decided they wanted to use in several places
50 RETURN
60 REM some more program
70 GOSUB 40
80 REM rest of program
90 END
That's just pretty much how BASIC required code to be structured. That's not Microsoft Basic or whatever the language evolved into over the generations. That's BASIC as it was originally designed and popularized. That's what those pages of listings looked like as you typed them in to your TRS-80 or VIC-20 or whatever from your favourite magazine.I guess it was put here cause it was thought it should look like this:
10 REM early bit of code
20 GOSUB 1010
30 REM some more program
40 GOSUB 1010
50 REM rest of program
60 END
1010 REM stuff they later decided they wanted to use in several places
1020 RETURN
Very much that.I guess it was put here cause it was thought it should look like this:
10 REM early bit of code 20 GOSUB 1010 30 REM some more program 40 GOSUB 1010 50 REM rest of program 60 END 1010 REM stuff they later decided they wanted to use in several places 1020 RETURN
Any instructor who says "NEVER" use GOTO may never have done much serious programming (where they are very useful for abnormal exiting of complex subroutines, and the horrors of number goto labels are long gone)
That depends on the language -- error cleanup based around goto is idiomatic in C, but in most modern languages the idiomatic thing to do is to use throw instead.
Any instructor who says "NEVER" use GOTO may never have done much serious programming (where they are very useful for abnormal exiting of complex subroutines, and the horrors of number goto labels are long gone)I'd probably still teach a class to never use goto, but then also teach that C error cleanup idiom as being the exception to this rule, and as a look inside how exceptional stack unwinding might be implemented in C++
I found Try and Catch to be about the same confuscation in complex code when a nice well named goto label can make clear not only where the jump is going (I indent in a way labels stick out) but also (can) describe why. I guess then its a matter of proper commenting for that anyway. I recall good ole Pascal in a class where the instructor didnt want gotos and having bothersome condition checking at every nested layer of loops/blocks to allow for the 'quick' exit.
I mention 'complex' code usually for this kind of issue because of the extra padding lines try/catch/finally can add to an already bulky/twisted block of code (and rethrowing exceptions out thru layers of calls...).
Systematic use of Gotos as part of a state engine scheme is another place I have commonly uses goto labels (where jumping upwards for retry situations can happen alot)