goto的基本思想是给你太多的自由去做你不想做的事情。它可能在与goto语句无关的地方导致错误，因此使代码维护更加困难。如果你认为你需要一个goto语句，你错了:)，你应该重新思考你的代码结构。这就是为什么现代编程语言投入了大量精力来提供可读的、可维护的流控制结构和异常处理机制。

我也不同意拉塞夫克的观点。由于goto被滥用的次数多于正确使用的次数，我相信它在设计良好的语言中没有一席之地。即使对于goto的“理想”用途，其他需要更多代码的方式也应该是首选。

所以总的来说，是的，它仍然被认为是有害的。

我们已经讨论过这个问题了，我坚持我的观点。

此外，我受够了人们将高级语言结构描述为“伪装的goto”，因为他们显然根本没有抓住重点。例如:

即使Scheme中先进的连续控制结构也可以被描述为复杂的后向。

那完全是胡说八道。每个控制结构都可以在goto方面实现，但这个观察完全是微不足道和无用的。Goto被认为是有害的，因为它的积极影响，而是因为它的消极后果，这些已经被结构化编程消除了。

Similarly, saying “GOTO is a tool, and as all tools, it can be used and abused” is completely off the mark. No modern construction worker would use a rock and claim it “is a tool.” Rocks have been replaced by hammers. goto has been replaced by control structures. If the construction worker were stranded in the wild without a hammer, of course he would use a rock instead. If a programmer has to use an inferior programming language that doesn't have feature X, well, of course she may have to use goto instead. But if she uses it anywhere else instead of the appropriate language feature she clearly hasn't understood the language properly and uses it wrongly. It's really as simple as that.

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

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。我有一系列五个嵌套计数循环，我需要能够根据某些条件从内部打破整个结构:

    for{
      for{
        for{
          for{
            for{
              if(stuff){
                GOTO ENDOFLOOPS;
              }
            }
          }
        }
      }
    }
    
    ENDOFLOOPS:

我可以很容易地声明一个布尔中断变量，并将其用作每个循环的条件的一部分，但在这种情况下，我认为GOTO是一样实用和一样可读的。

没有迅猛龙攻击我。

在我所见过的每个平台上，高级控制结构都被实现为低级的goto(跳转)。例如，Java虚拟机有一个跳转字节码，但是没有if、else、while、For等字节码。

其中一些编译器会为一个简单的条件块创建意大利面条代码。

回答你的问题，去走仍然被那些认为它有害的人认为是有害的。Goto很容易失去结构化编程的优点。

最后，这是你的程序;所以你的决定。我建议在您能够自己回答问题之前不要使用goto，而是在特定问题的上下文中使用。

许多现代编程语言使用它们的编译器来强制限制GOTO的使用——这减少了潜在的风险。例如，c#不允许您使用GOTO从循环体外部跳转到循环体。文档中提到了限制。

这是GOTO有时比过去更安全的一个例子。

在某些情况下，GOTO的使用与提前从函数返回相同(即提前跳出循环)。然而，良好的形式是有争议的。