几乎所有可以使用goto的情况，都可以使用其他结构实现相同的效果。无论如何，编译器都会使用Goto。

我个人从来没有明确地使用它，也不需要。

我只需要它在基本(即。VB, VBScript等)和批处理文件。然后我只将它用于错误处理。在Basic中，我倾向于只使用“on error goto”。在批处理文件中，我必须使用它，因为没有其他命令。然后，我只使用它们作为向前跳转到有意义的标签。

实际上，我发现自己不得不使用goto，因为我真的想不出更好(更快)的方法来编写这段代码:

我有一个复杂的对象，我需要对它做一些操作。如果对象处于一种状态，那么我就可以进行快速操作，否则我就必须进行慢速操作。问题是，在某些情况下，在缓慢的手术过程中，可能会意识到这可以用快速手术来完成。

SomeObject someObject;    

if (someObject.IsComplex())    // this test is trivial
{
    // begin slow calculations here
    if (result of calculations)
    {
        // just discovered that I could use the fast calculation !
        goto Fast_Calculations;
    }
    // do the rest of the slow calculations here
    return;
}

if (someObject.IsmediumComplex())    // this test is slightly less trivial
{
    Fast_Calculations:
    // Do fast calculations
    return;
}

// object is simple, no calculations needed.

这是一个实时UI代码的速度关键部分，所以我真的认为GOTO在这里是合理的。

Hugo

如果GOTO本身是邪恶的，那么编译器也是邪恶的，因为它们生成jmp。如果跳转到代码块，特别是跟随一个指针，在本质上是邪恶的，那么RETurn指令就是邪恶的。相反，邪恶在于滥用的可能性。

有时我不得不编写应用程序，必须跟踪许多对象，其中每个对象必须遵循复杂的状态序列来响应事件，但整个事情绝对是单线程的。一个典型的状态序列，如果用伪代码表示，将是:

request something
wait for it to be done
while some condition
    request something
    wait for it
    if one response
        while another condition
            request something
            wait for it
            do something
        endwhile
        request one more thing
        wait for it
    else if some other response
        ... some other similar sequence ...
    ... etc, etc.
endwhile

我相信这不是新的，但我在C(++)中处理它的方式是定义一些宏:

#define WAIT(n) do{state=(n); enque(this); return; L##n:;}while(0)
#define DONE state = -1

#define DISPATCH0 if state < 0) return;
#define DISPATCH1 if(state==1) goto L1; DISPATCH0
#define DISPATCH2 if(state==2) goto L2; DISPATCH1
#define DISPATCH3 if(state==3) goto L3; DISPATCH2
#define DISPATCH4 if(state==4) goto L4; DISPATCH3
... as needed ...

然后(假设初始状态为0)上面的结构化状态机转换为结构化代码:

{
    DISPATCH4; // or as high a number as needed
    request something;
    WAIT(1); // each WAIT has a different number
    while (some condition){
        request something;
        WAIT(2);
        if (one response){
            while (another condition){
                request something;
                WAIT(3);
                do something;
            }
            request one more thing;
            WAIT(4);
        }
        else if (some other response){
            ... some other similar sequence ...
        }
        ... etc, etc.
    }
    DONE;
}

在此基础上，可以有CALL和RETURN，因此一些状态机可以像其他状态机的子例程一样工作。

不寻常吗?是的。维护者是否需要学习一些知识?是的。这种学习有回报吗?我想是的。如果没有跳转到方块中的goto，游戏还能完成吗?不。

GOTO就像台锯，在采取适当的安全措施时非常有用。

我认为这是有害的，因为大多数初学者都失去了桌子锯和goto的手指。

在某些情况下，这是控制心流的唯一方法，但这些情况是可以避免的。

今天，很难看出GOTO语句有什么大不了的，因为“结构化编程”的人赢得了这场辩论，今天的语言有足够的控制流结构来避免GOTO。

计算现代C程序中goto的数量。现在添加break、continue和return语句的数量。此外，加上你使用if、else、while、switch或case的次数。这是1968年Dijkstra写这封信时，如果你用FORTRAN或BASIC语言编写程序，你的程序会有多少个goto。

当时的编程语言缺乏控制流程。例如，在最初的达特茅斯BASIC中:

IF statements had no ELSE. If you wanted one, you had to write: 100 IF NOT condition THEN GOTO 200 ...stuff to do if condition is true... 190 GOTO 300 200 REM else ...stuff to do if condition is false... 300 REM end if Even if your IF statement didn't need an ELSE, it was still limited to a single line, which usually consisted of a GOTO. There was no DO...LOOP statement. For non-FOR loops, you had to end the loop with an explicit GOTO or IF...GOTO back to the beginning. There was no SELECT CASE. You had to use ON...GOTO.

因此，您的程序中最终出现了许多goto。并且您不能依赖于goto限制在单个子例程中(因为GOSUB…RETURN是一个非常弱的子例程概念)，所以这些goto可以去任何地方。显然，这使得控制流难以遵循。

这就是反goto运动的由来。