Re: Exit(n) vs. goto
18/02/2002 9:17:52 AM, kbochert at ix.netcom.com wrote:
>
>Hi Derek Parnell, you wrote on 2/17/02 12:30:56 PM:
>
Firstly, I'm not arguing for or against the GOTO per se in this particular
discussion. I could! But
I'm not. I'm specifically examining the use of GOTO as a method of exiting
loops.
>>Goto is more semanticly meaningful, more
>>versatile, runs faster and its target is more
>>easily found.
>
>
>>This is where we part company. If we use "semanticly" to mean that it
>>conveys meaning, then GOTO is in fact less semantically meaningful than
>>EXIT. My reasoning is that GOTO means that the logic flow jumps somewhere
>>into the code.
>
>'goto error' seems fairly meaningful, especially as compared
>to 'exit(3)'.
>
Maybe? I'm not sure. To me, GOTO means "jump somewhere", and EXIT means "I want
to leave a loop".
The difference is that a GOTO does not convey the coder's intention where as
EXIT has a better
chance of doing that. Even with disciplined naming conventions, a GOTO can still
mislead a person
reading the code.
With a GOTO, it is never clear from the statement itself, if the coder is trying
to leave a loop or
not. One can only know if you find the target of the GOTO and see if it is
outside the loop or not.
Even if the coder writes "GOTO exit_srchloop" we cannot be sure if the label
exit_srchloop is
actually outside the loop or not until we locate it when reading the code.
There is always a danger in trying to convey meaning in an identifier's name. Of
course we all try
do that, but often it is hard. I'm reminded of a (stupid?) junior programmer
that thought he has
having a joke and coded something like this...
constant HUNDRED = 100,
THOUSAND = 10 * HUNDRED - 1,
MILLION = 10 * THOUSAND
and thus when the constants were used in code, other people would have a
terrible time trying to
debug the code when reading it. Or a Forth programmer doing this : + - ;
(redefining the plus sign
to mean minus!).
>>Another method of identify the loop is to give it a name, which of course
>>doesn't change as you modify the code in future. Then the EXIT statement
>>nominates the name of the loop it wants to exit. In this way we get the
>>semantic benefit (EXIT means leave a loop), and maintenance benefit (the
>>loop's name doesn't change unless we specifically change it).
>>
>
>Much better. I am not opposed to 'exit' or 'exit (srch_loop)'. (But
>'exit (srch_loop)' seems pretty equivalent to 'goto end_srch_loop').
>
It is except that EXIT tells you that the coder wants to leave a loop, but GOTO
only tells you that
the coder wants to go somewhere else.
>> And it avoids the potential problem of jumping to
>>arbitrary code location that is NOT the end of a loop.
>
>One programmer's potential problem is another's tool.
>
Again, I'm not talking about GOTO per se, just leaving a loop. Consider...
for i = 1 to 100 do
. . .
if x then goto exit_scan end if
. . .
end for
cnt += 1
:exit_scan:
In this case, not only does the code leave the loop, it also ignores the code
immediately following
the loop, thus possibly introducing a bug and misleading a person reading the
loop code. It is made
even more misleading because it allows for this too:
if y then goto exit_scan end if
for i = 1 to 100 do
. . .
if x then goto exit_scan end if
. . .
end for
cnt += 1
:exit_scan:
Now, the label 'exit_scan' has really lost its meaning. This does not help
people reading your code.
>> Also with GOTO one
>>must seek its target when looking through the code. It could be earlier or
>>later than the loop we are in.
>>
>
>I would rather search for the label than take the risk of miscounting
>'end while/for' as I scan through multiple pages. In practice,
>the name of the lable usually indicates its direction, and an editor's
>search capability make this easy.
>
Me too. That's one of the reasons I don't like exit(n) syntax.
>>I wouldn't want to introduce a syntax for this concept yet but I'm sure the
>>example below is self-explanitory...
>>
>> Scans:for i = 1 to length(s) do
>> c = getc(h)
>> while find(c, charlist) do
>> if c = AbortCode then
>> exit (ScanS)
>> end if
>> RoutineA(c)
>> end while
>> RoutineB()
>> end Scans
>>
>Not bad. Use of 'end Scans' instead of 'end for' greatly
>simplifies finding the target of exit, and should also
>improve the readability.
Thank you.
>Shouldn't you also have a 'continue (Scans)' statement?
>Given that this exercise is to simplify nested loops, it would
>be a shame to add an enclosing while loop just to be able to
>restart a loop.
Yes, I think this idea is also a good one, and I've discussed this with RDS
before. Using named
loops make the ideas of moving on to the next iteration and repeating the same
iteration much easier
on the eyes.
for i = 1 to 100 do:ScanLoop
. . .
-- Do the next iteration
if c then next Scanloop end if
. . .
-- Repeat the same iteration
if d then repeat Scanloop end if
. . .
-- Leave the loop
if e then exit ScanLoop end if
. . .
end ScanLoop
---------
Cheers,
Derek Parnell
|
Not Categorized, Please Help
|
|
