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

当然，可以使用GOTO，但是有一件事比代码风格更重要，或者在使用它时，您必须考虑到代码是否可读:其中的代码可能不像您想象的那样健壮。

例如，看看下面的两个代码片段:

If A <> 0 Then A = 0 EndIf
Write("Value of A:" + A)

GOTO的等效代码

If A == 0 Then GOTO FINAL EndIf
   A = 0
FINAL:
Write("Value of A:" + A)

我们首先想到的是这两段代码的结果将是“Value of A: 0”(当然，我们假设执行没有并行性)

这是不正确的:在第一个示例中，A将始终为0，但在第二个示例中(使用GOTO语句)A可能不是0。为什么?

原因是，从程序的另一点，我可以插入一个GOTO FINAL而不控制a的值。

这个例子非常明显，但是随着程序变得越来越复杂，看到这些东西的难度也增加了。

相关材料可以在Dijkstra先生的著名文章“反对GO TO声明的案例”中找到

关于goto语句，它们的合法用途，以及可以用来代替“有道德的goto语句”但也可以像goto语句一样容易被滥用的替代结构，最深思熟虑和彻底的讨论是Donald Knuth的文章“使用goto语句的结构化编程”，在1974年12月的Computing Surveys(卷6,no. 1)中。4. 第261 - 301页)。

毫不奇怪，这篇39年前的论文的某些方面已经过时了:处理能力的数量级增长使得Knuth的一些性能改进对于中等规模的问题来说并不明显，从那时起就发明了新的编程语言结构。(例如，try-catch块包含Zahn的Construct，尽管它们很少以这种方式使用。)但Knuth涵盖了争论的方方面面，在任何人再次重复这个问题之前，都应该要求阅读。

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

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

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

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

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

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

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

# ifdef TONGUE_IN_CHEEK

Perl有一个goto，它允许您实现穷人的尾部调用。: - p

sub factorial {
    my ($n, $acc) = (@_, 1);
    return $acc if $n < 1;
    @_ = ($n - 1, $acc * $n);
    goto &factorial;
}

# endif

好吧，所以这和C的goto没有关系。更重要的是，我同意其他关于使用goto进行清理或实现Duff的设备等的评论。这都是关于利用，而不是滥用。

(同样的注释可以应用于longjmp、异常、call/cc等等——它们有合法的用途，但很容易被滥用。例如，在完全非异常的情况下，抛出异常纯粹是为了转义深度嵌套的控制结构。)

在Perl中，使用标签从循环中“goto”—使用“last”语句，这类似于break。

这样可以更好地控制嵌套循环。

也支持传统的goto标签，但我不确定是否有太多的实例，这是实现您想要的结果的唯一方法-子例程和循环应该足以满足大多数情况。