in reply to GOTO or not GOTO

From a high level perspective you don't need a goto statement. The argument that it can lead to unreadable code is a good one. But just because misuse of the goto statement can be harmful, it doesn't mean that it shouldn't be part of your toolbox.

The goto doesn't kill code, bad programming does!

There is a business case for the goto, see for example "argument for goto".

Replies are listed 'Best First'.
Re^2: GOTO or not GOTO
by tilly (Archbishop) on Jan 27, 2009 at 11:17 UTC
    The arguments in that essay are a poor rendition of the arguments that Knuth gave in Structured Programming with Go To Statements. However if you read that essay carefully you will realize that modern exception handling is better for handling errors than goto, and the remaining efficiency points are all addressed completely by labeled loop control. (In fact Knuth refers to a paper proving the second point, however at the time that point was theoretical only since no languages had that feature back then. However Perl does.)

    That is not to say that there are not cases where goto is still useful. But they are very rare. I can only think of 3 that I have ever seen in Perl, and none of them were in code that I wrote.

Re^2: GOTO or not GOTO
by DrHyde (Prior) on Jan 27, 2009 at 10:36 UTC
    Bravo! I don't feel particularly compelled to justify my use of goto here for example.
      I would personally replace it with a redo on a bare block. That bare block would also be a hint to indent the potentially redone section of code, which naturally draws attention to that control structure.

      General rule of thumb. Any normal use of goto can be replaced by an entirely equivalent loop control statement, possibly using labels when breaking out of multiple levels of loops. Unless there is a good reason not to, I prefer that approach.

        Any normal use of goto can be replaced by an entirely equivalent loop control statement, possibly using labels when breaking out of multiple levels of loops.
        This is exactly why in some cases I prefer goto over loop control statements. A loop introduces a block. Variabled my()ed in the block don't live outside them - if they are needed after the block (or goto destination), you have to separate the my() and the first initialization. Which is something I prefer not to. Second, sometimes you encounter code that, if turned into nested loops instead of gotos, will be nested deeply. Which can lead to a narrow strip of code on the right hand side of the window.

        Now, that doesn't mean I use goto lightly. But I may opt for a goto instead of loop control two or three times a year.