Mail Archives: djgpp/2000/08/05/14:05:45
On Thu, 03 Aug 2000 20:36:39 GMT, manni DOT heumann AT gmx DOT de (Manni Heumann)
wrote:
>djgpp AT delorie DOT com wrote:
>>>Try 'goto'. You'll love it. They never taught you about it in
>>>school.
>>
>>EEK! There are reasons for this! GoTo is "forbidden"! Nicer is to put this
>>into a function
>>that returns TRUE/FALSE. So, as soon as a collition is detected, you jump
>>out of the
>>function with false. This will break the loops. Might be considered cheating
>>but it
>>helps for making the code more usable so there is a good fix to this
>>problem.
>>
>
>Name just one of those reasons agains goto, other then "it looks like
>BASIC and real hardcore C coders don't use that kiddy stuff."!
>
>I didn't yet see one solution in this thread, that was as easy to read
>as a simple little goto. Checking a flag for every for, building the
>whole nest in a function and return? Picture yourself reading that
>code! Goto will also give you the benefit of feeling superior to the
>moron who still uses goto after all this years:-)
>
>Back to the beginning: Name one reason against using goto. At least
>name the law the forbids using goto.
sure here are a few:
debugging
maintaining
comprehension
experience (at this point I'm not counting anymore but it's over 25
years) teaches most, and I am in the group of believers, that goto's
are crutches that help get out of a problem you didn't understand well
enough to avoid getting in a situation that requires them in the first
place.
I refrained from jumping into this thread because I didn't have the
time to properly address the points I thought needed to brought up. I
still don't have time right now and I'll be out of town for a few days
due to a family emergency so I won't be able to properly follow this
thread. But I will mention that when I first saw this little snippet
of code, my first thought was that this was an example from a book on
what your code should NOT do. This code is litterally riddled with
traps for th;e reader and for the program. Nearly every line could be
rewritten to be clearer to read and comprehend, to be easier to
maintain, and to debug. The code as it's writen has many points of
logical confusion if not outright errors.
As one example, look at the two if statements. Each is written with a
first test that checks for a value of less than or equal to 0. Then
followed by an empty block then comes an else clause that test to make
sure the value is Not equal to 0. Since the only value that will fail
the first test and excute the second test is greater than 0 the second
test is uneeded. By rewriting the first test to read greater than 0
you eliminate the else clause, reduce the amount of code, speed up the
program, make it clearer to read and comprehend, and easier to debug.
None of that addressed another LITTLE problem. As its written here,
this code will always go to FUNCtion no matter what: in other words
finding a collision didn't really do anything as far as the target of
your proposed "GOTO". If FUNCtion intends on using the detected
collision, then there's the problem of getting the location of the
collision out of the nested loops. As writen, neither a nor b should
exist after the loops are exited. If the FUNCtion doesn't care about
the collision, then the entire test seems like it could be eliminated
and make things faster, easier to read, and debug.
There are quite a few other points, but I'll let these stand for now.
In this case a GOTO is merely another warning flag that this section
of code needs more attention.
The theory of structured programming expresses thae point that
complex program flows or multiple paths through a section of code are
harder to manage and mentally track. The theory says that one entry
point and one exit point fom a section of code allow you to better
control the state of the program environment. GOTO's create multiple
exits from a section of code and require a programmer to mentally keep
track of different exit states from a section of code.
In this case the nested loops are used to examine points from (1,1) to
(pptest_w, pptest_h). There two possible outcomes possible. Either you
find a collision or you don't. As written the normal exit condition of
this code is when you don't find a collision and it's unclear what
should happen next. The alternative is to detect a collision and then
perform FUNCtion(). So one very real posility is to simply move the
call to FUNCtion() to the point where the collision is detected. IN
other words to call the function from the loops instead of trying to
find a way out of the confusing logic and control stuctures to get to
the next line of code.
Structured programming is not always the best solution and it won't
always be the best solution in every case. But it is a very good
guideline that captures a lot of programmer experience built from the
beggining of programmable computers. To disregard it lightly is to be
condemned to relive and relearn history. On the other hand GOTO is not
always wrong either, but it is always a flag that something has
happened that the programmer can't handle. One use where you continue
to see goto's in even experienced programmers code is when something
happens that can't be recovered from. Error conditions sometimes call
for you to abandon the program logic and head for the nearest exit,
literally. Either way a programmer should try to use the lessons
learned alreay to avoid making the same mistakes from the past. We
need to improve and make entirely NEW mistakes. We owe that to the
future programmers :)
>
>Come on, convince me!
In this case, I'd say you might want to convince yourself. Try and
improve the code as it's written. Do it with goto's and without and
see which one is better for you. Don't forget to go back 6 weeks from
now and reread your code to see if the startling clarity you see now
is still there. And try to modify the code in a few months.
Good luck!
- Raw text -