On Sat, 25 Jun 2016 01:21:33 +0200
Irrwahn <irrwahn@???> wrote:

> For the
> interested, David Tribble's "Go To Statement Considered
> Harmful: A Retrospective"[4] makes for a good read.
>
>
> [1] NB: "break" and "continue" are just "goto" in disguise.
>

> [2] For example in the notorious case of releasing resources 
>     in reverse order of allocation in the event of an error.

>

> [3] Lame attempt at translating a witticism once made by a 
>     German politician.

>
> [4] http://david.tribble.com/text/goto.html

Ugh!

I knew to be skeptical when the author, in the 3rd paragraph, called
the evilness of goto a "myth". Agenda alert!

First of all, we all need to get on the same page as to what we're
talking about. By my definitions, "break" and "continue" and for that
matter exit(1) or exit 1 and exceptions are in no way gotos in disguise.
They're program counter alterations that break modularity (which goto
does too), but break it in a very predictable and reasonably unharmful
way. Real goto statements, with labels you can put anywhere, are
extremely prone to utter destruction of modularity. I know: I started
programming with gotos, because I started designing with flowcharts.

With a flowchart based design, flow control ricochets around like a
laser pen in a house of mirrors. If you like systemd, you'll love
flowchart based design. And of course, the way to implement flowchart
based design in code is with gotos. The Flowchart fellows of the
1960s/70's were clever: In many cases too clever for their own good.
They were clever enough to make it, but not to debug it. And because
the functional decomposition design method that I replaced flowcharts
with was much more productive, they lost out in the marketplace to more
productive programmers.

If you want to see my opinion on gotos and flowcharts, and how I came
upon this opinion, go to
http://www.troubleshooters.com/lpm/200310/200310.htm, search for
"Whomping Out the Code", and read the next two paragraphs. If one uses
gotos, one must be VERY careful. It's called spaghetti programming for
a reason.

Then there's the old excuse "well, you might need to escape a deeply
nested loop. No problem, encapsulate the outer loop from which you want
to escape in a function, and use the return statement wherever you want
to bust out of the nested loop. If some cleanup needs to be done
before the loop-bust, call the cleanup as another function. Or if you
want to bust out of the whole program, use exit() or an exception. Just
don't use a goto with a label. Because someday some well meaning but
dumb maintenance programmer will put code between the end of the
outer loop and the label, and then all hell will break loose.

If you look at the article's annotated Dijkstra essay, Dijkstra
repeatedly says "goto statement", not just "goto" as a concept. He
wasn't talking about break, nor continue, nor return, nor an exception.
Break, continue, return, exit() and exceptions perform a jump without a
corresponding "return from subroutine", which is unmodular and
unstructured, but they jump to places specified by their placement in
the program, not specified by some label the programmer can place
absolutely anywhere.

I'm not kidding: My programming ability improved by over an order of
magnitude when I stopped using goto statements with moveable labels,
and in my opinion anyone wanting to use a goto with a moveable label
should explain in detail why he can't achieve the same result with
structures such as break, continue, return, exit(), an exception, or
the real structured solution: Loops with flags that can be turned
false, and if statements such that nothing from the current loop is
executed after the flag is turned false.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb