I found this in my old emails... :)

I believe some of us don't have a very convincing explanation for why "GoTo" should not b used. Mostly, we avoid it more b'cos we believe its dangerous & bad practice in general than for any other reason. The following Q&A I found in some cpp tips site, comes close to giving a justification. Does anyone have anything (and time, of course) to add to it?

TITLE: Thoughts on the use of "goto"

PROBLEM:
I submit that what is really at issue is the code complexity. Controlling complexity goes to the heart of the entire structured and object oriented programming movements. And while GOTO statements, break statements, and multiple returns from subroutines go against structured programming dogma, the evidence of our eyes is that these can be used to simplify code.


RESPONSE:

This is undeniably true. The careful use of GOTO can shrink code dramatically. However there is a cost. The reason the code shrinks is that you *assume* that you can branch to an area of common code in all circumstances; and that this fact will remain true throughout the lifetime of the product.

Such assumptions create dependencies. The common code depends upon conditions set up by the branching code, and the branching code depends upon operations preformed by the common code.

Managing these dependencies during initial project development is usually not too difficult. But as the program evolves over its lifecycle, counter examples will be created. The strategy will be to use flags and other context sensitive means to "condition" the commoncode to preform correctly. Thus even more dependencies will be created. The end is usually sad.

Let me make a point. You said that "controlling complexity goes to the heart of OO". I agree. However you have implied that complexity is the equivalent of code size. I disagree. And to back that up I have the observation that OO programs usually have more lines than equivalent procedural programs do -- at first. At the end of their lifecycle, the opposite is generally true; that OO programs will have fewer lines then their equivalent procedural programs do.

Why? Because the complexity being managed is not the instantaneous complexity of the current code, it is the complexity of the lifecycle of the product. Often in OOD we add lines of code in order to build an infrastructure that will be stable throught the anticipated lifecycle. That infrastructure breaks dependencies that would exist in the equivalent procedural program.

Using structured techniques has a larger short term cost than breaking structure and using gotos. Using OO techniques has a larger short term cost than breaking the object model and using procedural techniques. The two trade-offs are exactly the same. And the long term costs of both shortcuts can be extreme. Short term thinking has utterly killed many very promising startups.

_____________________________________________________________________________________________________________________

"Twenty years ago I knew everything. Now I know nothing. Education is a progressive discovery of our own ignorance"
- H L Mencken
_____________________________________________________________________________________________________________________

-Author Unknown

I like to avoid constructs like 'break' and 'goto' as much as possible in the little programming I do. Thinking about, I never really use them, except maybe in an awk script. I think it's ok to use them to break out of loops (if unavoidable) or for error handling. Otherwise, you should rework your code so that they are not necessary.

Just my 2 cents.

Ah, where are the old days of using 'goto' and 'gosub' in BASIC and end up with a massive spaghetti code jungle :D

I don't use any goto statement, but, I think, the break are unavoidable and don't add so much confusion to the code.

I have only to add one little remark:

In Baan Tools 4GL, when we use an instruction like:

field.xxxxx:
before.field:
....
after.input:
.....


in fact, we use a label that defines a "section" of software that will be executed during the flow of the form fields.
The order on which the fields are executed is determined in the form itself and isn't immediately visible looking at the form, so in fact, there are a lot of "invisibles" GOTO :mad: in almost all Baan 4GL scripts....:eek:

Almost true,

Because Baan is event driven, the events are handled sequential. This means there is a clear structure (http://www.baanboard.com/programmers_manual_baanerp_help_4gl_features_flow_of_standard_program) for the events. Run a report in debug mode to get an idea on how the sections are handled (not like goto but like sequence of separate functions).