[KenWittlief]

there is another aspect to shortcuts like goto and recursion.

In SW and HW you always want to keep your program sequence and flow control separate from your data processing

gotos and recursion violate that - what I mean is your code should look like

decision statement (will the flollowing code be executed?)
---data processing equation (outputs are a function of inputs)
---equation
---equation
---equation
---equation
---equation
---equation

decision statement (will the following code be executed?)
--- data processing equation (outputs are a function of inputs)
---equation
---equation
---equation
---equation
---equation
---equation
what goto statements do is inject a program flow statement in the middle of the data processing equations - intermixing your data and control leads to nightmares - and there really is no reason for it (which is why the professors would give you an F, there is no excuse)

humans can only think one or two steps ahead at a time - if you have a block of code, with a conditional execution statement at the top, and then two or more conditional exits (gotos) inside the data equations - it becomes impossible to look at the code and understand what its going to do in every case.

I cant put this in the right words, so here is a challenge. Next time you feel tempted to use a goto statement in a high level language, go back to the algorythm or flowchart, or bubble diagram, and figure out what you would have to do to get rid of the goto statement - and you will see how the change makes the code cleaner, simpler, and easier to read and debug.