[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Computing Editorial (please read)
- Subject: Re: Computing Editorial (please read)
- From: dalloff@gcfn.org (Dave Althoff Jr)
- Date: 20 Jan 2003 16:53:19 -0500
- Newsgroups: comp.sys.apple2
- Organization: The Greater Columbus Free-Net
- References: <b0elt6$ra7$1@freenet9.carleton.ca> <20030119173241.20075.00000146@mb-cu.aol.com> <3e2b66dd$0$179$45beb828@newscene.com> <b0g1ie$gvd$1@ronco.freenet.columbus.oh.us> <Xns93091804A3AFmenacechgoaolcom@206.141.192.32> <b0g5as$acm$1@freenet9.carleton.ca>
- Xref: archiver1.google.com comp.sys.apple2:26335
Michael Black (et472@FreeNet.Carleton.CA) wrote:
(I defended GOTO, and Marsha defended me)
: But what do you do at the other end of the GOTO? Either it's the end
: of the program, or you'll have to put another GOTO at the end, to send
: you somewhere else. I don't think the taboo against GOTOs concerns
: itself so much with the initial jump, but that spaghetti at the
: end to bring you back. And probably too the weaving that some might
: do for no particular reason other than that you can do it, or
: because they can't properly visualize the layers of the program.
Well, in the case of my ObjectPAL code, where I want the GOTO is usually
because I completed some condition testing and now I want to skip over the
whole rest of the script and get to the end. I learned a long time ago
about the importance of single exit points...but I have ObjectPAL code
where the script ends with...
> endif
> endif
> endif
> endif
> endif
> endif
> endmethod
It's hardly clean code. And I come from a world without ELSE so my gut
feeling is to get out of IF constructs as quickly as possible
: Subroutines make for much cleaner code. I don't believe I was
: reading about the evil GOTO when I started programming, but I learned
: pretty early the usefulness of subroutines. Map out the main loop,
: and start with dummy subroutines. Then work on the subroutines. Or,
: work on the subroutines first, figuring out little bits of code
: by themselves, and then fitting them together with some other code
: later. I found it all worked out quite nicely, the experience pointed
: to the usefulness.
Subroutines are great where they make sense. If it's code you're only
gonna reference once from the main loop, though, you might as well put it
in the main loop. Another valid use for GOTO, of course, is to close the
main program loop. In the programs I have written, there were always a
variety of options in the main loop, and one of those options was to QUIT.
I was never one to make "quit" a special case, particularly since I like
using ON...GOSUB to branch to the subroutines. So the main loop was
closed not with an "IF NOT QUIT" structure, but rather a simple GOTO. The
quit code was a subroutine that would clean up the screen, fix any
pointers the program had munged, pop the stack, and erase the program from
memory:
63999 TEXT:NORMAL:PRINT CHR$(21):HOME:PRINT "Bye!":POP:PRINT CHR$(4);"FP"
More often, instead of using ON..GOSUB off the main loop, I'd use
ON...GOTO, then return to the top of the main loop using a GOTO at the end
of the handler routine. That actually presented a cleaner way of handling
quit code, as a program exit (or completion) was the only code that would
fall through the main loop. The advantage to that was that different
routines could return to different points in the main loop as required.
For instance, the main loop might have code that looks something like this:
1000 PRINT CHR$(4);"PR#3":PRINT:PRINT
1005 HOME:POKE 36,35:PRINT "Main menu:"
Almost all of the menu option handlers would end with a GOTO 1005, EXCEPT
for the one that (for instance) does printing and messes up the I/O hooks
and therefore needs a more complete screen initialization when it returns.
That said, this kind of programming still requires some discipline. GOTOs
are not always evil, but they can easily get that way. 8-)
: Since the 6502 didn't have conditional jump to subroutines, I even
: figured out myself that it made sense to jsr to the condition testing
: when then branched to the subroutines. An rts at the end of the subroutine
: then brought you back up to where you'd originally jumped from, rather
: than having to put code in the conditional testing.
Personally, I like the technique that Apple used for, for instance, DOS
command handling...where the subroutine address is pushed onto the stack
and then instead of a JSR, JMP, or conditional branch, the routine
branches to the command handler using...an RTS!
--Dave Althoff, ][.
--
/-\ _ _ *** Thanks for a great season!! ***
/XXX\ /X\ /X\_ _ /X\__ _ _ _____
/XXXXX\ /XXX\ _/XXXX\_ /X\ /XXXXX\ /X\ /X\ /XXXXX
_/XXXXXXX\__/XXXXX\/XXXXXXXX\_/XXX\_/XXXXXXX\__/XXX\_/XXX\_/\_/XXXXXX