Over the years I have seen repeated comments in these newsgroups
that using GOTOs in the code is something to be avoided.
[....]
What are the pitfalls/problems that might/may occur from using GOTOs?
Ahh, memories of Dykstra's "GoTos Are Considered Harmful" manifesto.
This is largely a religious issue, not unlike the abortion issue.
There are advocates on both extremes, with a large group in the
middle.
Suffice it to say: there is nothing inherently wrong with GOTOs. It
is how they are used or misused that matters.
I and many others -- including Dykstra eventually -- believe that the
judicious use of GOTOs can even improve the readabillity of some
programs. Conversely, the dogmatic avoidance of GOTOs can lead to
code that is difficult to read and maintain, and it is sometimes very
much less efficient.
It all started in the 1960s, when computer scientists started
developing proofs of program correctness and branch analysis
techniques. The latter became the cornerstone of modern compilers and
debugging tools. The so-called "unstructured" use of GOTOs made those
tasks difficult, even impossible in many cases. Hence the invention
of "structured programming", with the goal that a block of code should
have only one entrance and one exit.
Almost immediately, most computer scientists recognized the need to
relax the "single exit" rule -- the so-called "n-and-a-half" loop
problem. So they invented statements like "break", "continue" and
"exit" in C. Those are essentially "structured" GOTOs. And it became
acceptable to use GOTO itself for those purposes, especially in
programming languages that lacked such statements.
However, it was still common to write "structured" algorithms that
included contorted deeply-nested IF statements. As a practical
matter, these can be minimized by a statement of the form "IF
condition THEN goto ..." around all the other stuff and by branching
out of the middle of an IF statement, just as one might branch out of
the middle of a loop.
Nonetheless, there is one use of GOTO that was not uncommon at the
time (1960s) and that deserves to be deprecated, namely: jumping into
the middle of a loop or an if-statement clause.
