因为goto使得程序流的推理变得困难。“意大利面条代码”)，goto通常只用于弥补缺失的功能:使用goto实际上可能是可以接受的，但前提是语言没有提供更结构化的变体来获得相同的目标。以《怀疑》为例:

我们使用的goto规则是，goto可以跳转到函数中的单个退出清理点。

这是对的——但前提是语言不允许使用清理代码进行结构化异常处理(如RAII或finally)，后者可以更好地完成相同的工作(因为它是专门为此而构建的)，或者有很好的理由不使用结构化异常处理(但除非在非常低的级别，否则您永远不会遇到这种情况)。

在大多数其他语言中，goto唯一可接受的用法是退出嵌套循环。即使在这种情况下，将外部循环提升为自己的方法并使用return也总是更好。

除此之外，goto是对特定代码段考虑不够的标志。

支持goto实现一些限制的现代语言(例如，goto可能不会跳转到函数中或跳出函数)，但问题从根本上还是一样的。

顺便说一句，其他语言特性当然也是如此，尤其是例外。而且通常有严格的规则，只在指定的地方使用这些特性，例如不使用异常来控制非异常程序流的规则。

我发现有趣的是，有些人会给出一个可以接受goto的例子列表，说所有其他的用法都是不可接受的。你真的认为你知道每种情况下goto是表达算法的最佳选择吗?

为了说明这一点，我将给你一个还没有人展示过的例子:

今天我在写代码，在哈希表中插入一个元素。哈希表是以前计算的缓存，可以随意重写(影响性能但不影响正确性)。

哈希表的每个桶都有4个槽，当桶满时，我有一堆标准来决定覆盖哪个元素。现在，这意味着在一个桶中最多要经过三次，就像这样:

// Overwrite an element with same hash key if it exists
for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
  if (slot_p[add_index].hash_key == hash_key)
    goto add;

// Otherwise, find first empty element
for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
  if ((slot_p[add_index].type == TT_ELEMENT_EMPTY)
    goto add;

// Additional passes go here...

add:
// element is written to the hash table here

如果不使用goto，代码会是什么样子?

就像这样:

// Overwrite an element with same hash key if it exists
for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
  if (slot_p[add_index].hash_key == hash_key)
    break;

if (add_index >= ELEMENTS_PER_BUCKET) {
  // Otherwise, find first empty element
  for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
    if ((slot_p[add_index].type == TT_ELEMENT_EMPTY)
      break;
  if (add_index >= ELEMENTS_PER_BUCKET)
   // Additional passes go here (nested further)...
}

// element is written to the hash table here

如果添加更多的遍数，它看起来会越来越糟，而带有goto的版本始终保持相同的缩进级别，并避免使用虚假的if语句，其结果由前一个循环的执行暗示。

所以在另一种情况下，goto使代码更清晰，更容易编写和理解……我相信还有更多的例子，所以不要假装知道所有goto有用的例子，而轻视任何你想不到的好例子。

因为goto使得程序流的推理变得困难。“意大利面条代码”)，goto通常只用于弥补缺失的功能:使用goto实际上可能是可以接受的，但前提是语言没有提供更结构化的变体来获得相同的目标。以《怀疑》为例:

我们使用的goto规则是，goto可以跳转到函数中的单个退出清理点。

这是对的——但前提是语言不允许使用清理代码进行结构化异常处理(如RAII或finally)，后者可以更好地完成相同的工作(因为它是专门为此而构建的)，或者有很好的理由不使用结构化异常处理(但除非在非常低的级别，否则您永远不会遇到这种情况)。

在大多数其他语言中，goto唯一可接受的用法是退出嵌套循环。即使在这种情况下，将外部循环提升为自己的方法并使用return也总是更好。

除此之外，goto是对特定代码段考虑不够的标志。

支持goto实现一些限制的现代语言(例如，goto可能不会跳转到函数中或跳出函数)，但问题从根本上还是一样的。

顺便说一句，其他语言特性当然也是如此，尤其是例外。而且通常有严格的规则，只在指定的地方使用这些特性，例如不使用异常来控制非异常程序流的规则。

“goto”的问题和“无goto编程”运动最重要的论点是，如果你过于频繁地使用它，尽管你的代码可能表现正确，但它会变得不可读、不可维护、不可审查等。在99.99%的情况下，“goto”会导致意大利面条代码。就我个人而言，我想不出任何好的理由来解释为什么我会使用“goto”。

嗯，有一件事总是比goto更糟糕;奇怪地使用其他程序流操作符来避免goto:

例子:

    // 1
    try{
      ...
      throw NoErrorException;
      ...
    } catch (const NoErrorException& noe){
      // This is the worst
    } 


    // 2
    do {
      ...break; 
      ...break;
    } while (false);


    // 3
    for(int i = 0;...) { 
      bool restartOuter = false;
      for (int j = 0;...) {
        if (...)
          restartOuter = true;
      if (restartOuter) {
        i = -1;
      }
    }

etc
etc

在Perl模块中，有时希望动态地创建子例程或闭包。问题是，一旦你创建了子例程，你如何得到它。你可以直接调用它，但是如果子例程使用caller()，那么它就没有那么有用了。这就是goto &子例程变化可能有用的地方。

这里有一个简单的例子:

sub AUTOLOAD{
  my($self) = @_;
  my $name = $AUTOLOAD;
  $name =~ s/.*:://;

  *{$name} = my($sub) = sub{
    # the body of the closure
  }

  goto $sub;

  # nothing after the goto will ever be executed.
}

您还可以使用这种形式的goto来提供尾部调用优化的基本形式。

sub factorial($){
  my($n,$tally) = (@_,1);

  return $tally if $n <= 1;

  $tally *= $n--;
  @_ = ($n,$tally);
  goto &factorial;
}

(在Perl 5 version 16中，最好写成goto __SUB__;)

有一个模块会导入尾修饰符，如果你不喜欢使用这种形式的goto，还有一个模块会导入递归。

use Sub::Call::Tail;
sub AUTOLOAD {
  ...
  tail &$sub( @_ );
}

use Sub::Call::Recur;
sub factorial($){
  my($n,$tally) = (@_,1);

  return $tally if $n <= 1;
  recur( $n-1, $tally * $n );
}

使用goto的大多数其他原因都可以用其他关键字更好地完成。

比如重写一段代码:

LABEL: ;
...
goto LABEL if $x;

{
  ...
  redo if $x;
}

或者从多个地方找到最后一段代码:

goto LABEL if $x;
...
goto LABEL if $y;
...
LABEL: ;

{
  last if $x;
  ...
  last if $y
  ...
}