On Sat, 25 Jun 2016 01:21:33 +0200 Irrwahn <[email protected]> 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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
