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

Using a goto makes it far too easy to write "spaghetti code" which is not particularly maintainable. The most important rule to follow is to write readable code, but of course it depends on what the goals of the project are. As a "best practice" avoiding a goto is a good idea. It's something extreme programming types would refer to as "code smell" because it indicates that you may be doing something wrong. Using a break while looping is remarkably similar to a goto, except it isn't a goto, but again is an indication that the code may not be optimal. This is why, I believe, it is also important to not find more modern programming loopholes which are essentially a goto by a different name.

在我看来，“goto有害”更多的是关于状态的封装和一致性。

许多代码，甚至是'oo'代码，都有像意大利面条代码一样糟糕的混乱状态封装。

“goto有害”的问题是，它让程序员只看机制规则而不理解这样的印象，即唯一可用的流控制应该是返回方法，这很容易导致通过引用传递许多状态——这又导致缺乏状态封装，而这正是“goto有害”试图摆脱的东西。

遵循典型的“OO”代码库中的控制流，并告诉我我们仍然没有意大利面条代码....(顺便说一下，我并不是指那些经常让人讨厌的“馄饨”代码——馄饨代码的执行路径通常是非常简单的，即使对象关系不是立即明显的)。

或者，换一种说法，避免gotos而将所有东西都作为子例程，只有在每个子例程只修改局部状态时才有用，只有通过该子例程(或至少该对象)才能修改局部状态。

如果你用C写一个VM，使用(gcc的)计算gotos是这样的:

char run(char *pc) {
    void *opcodes[3] = {&&op_inc, &&op_lda_direct, &&op_hlt};
    #define NEXT_INSTR(stride) goto *(opcodes[*(pc += stride)])
    NEXT_INSTR(0);
    op_inc:
    ++acc;
    NEXT_INSTR(1);
    op_lda_direct:
    acc = ram[++pc];
    NEXT_INSTR(1);
    op_hlt:
    return acc;
}

工作速度比循环内的传统开关快得多。

以下陈述是概括;尽管抗辩例外总是可能的，但通常(以我的经验和拙见)不值得冒险。

Unconstrained use of memory addresses (either GOTO or raw pointers) provides too many opportunities to make easily avoidable mistakes. The more ways there are to arrive at a particular "location" in the code, the less confident one can be about what the state of the system is at that point. (See below.) Structured programming IMHO is less about "avoiding GOTOs" and more about making the structure of the code match the structure of the data. For example, a repeating data structure (e.g. array, sequential file, etc.) is naturally processed by a repeated unit of code. Having built-in structures (e.g. while, for, until, for-each, etc.) allows the programmer to avoid the tedium of repeating the same cliched code patterns. Even if GOTO is low-level implementation detail (not always the case!) it's below the level that the programmer should be thinking. How many programmers balance their personal checkbooks in raw binary? How many programmers worry about which sector on the disk contains a particular record, instead of just providing a key to a database engine (and how many ways could things go wrong if we really wrote all of our programs in terms of physical disk sectors)?

以上附注:

关于第2点，考虑以下代码:

    a = b + 1
    /* do something with a */

在代码中的“do something”点，我们可以高度自信地声明a大于b。(是的，我忽略了未捕获整数溢出的可能性。我们不要拘泥于一个简单的例子。)

另一方面，如果代码是这样读的:

    ...
    goto 10
    ...
    a = b + 1
    10: /* do something with a */
    ...
    goto 10
    ...

标记10的方法的多样性意味着我们必须更加努力才能确信a和b在这一点上的关系。(事实上，在一般情况下，这是不可判断的!)

关于第4点，代码中“去某个地方”的整个概念只是一个比喻。除了电子和光子(用于余热)，CPU内部没有任何东西真正“去”到任何地方。有时候，我们会放弃一个比喻，转而使用另一个更有用的比喻。我记得(几十年前!)遇到过一种语言

    if (some condition) {
      action-1
    } else {
      action-2
    }

通过将action-1和action-2编译为行外无参数例程，然后使用单个双参数VM操作码(使用条件的布尔值来调用其中一个)在虚拟机上实现。这个概念只是“选择现在调用什么”，而不是“去这里或去那里”。再一次，换一个比喻。

如果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，游戏还能完成吗?不。