计算机科学家Edsger Dijkstra在该领域做出了重大贡献，他也因批评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不好的一个原因是，除了编码风格之外，你可以用它来创建重叠但非嵌套的循环:

loop1:
  a
loop2:
  b
  if(cond1) goto loop1
  c
  if(cond2) goto loop2

这将创建一个奇怪的，但可能是合法的流控制结构，其中可能有(a, b, c, b, a, b, a, b, b，…)这样的序列，这让编译器黑客不高兴。显然，有许多聪明的优化技巧依赖于这种类型的结构不发生。(我应该检查一下我的龙书……)这样做的结果(使用一些编译器)可能是对包含gotos的代码没有进行其他优化。

如果你知道它只是“哦，顺便说一下”，恰好说服编译器发出更快的代码，那么它可能会很有用。就我个人而言，我更喜欢在使用像goto这样的技巧之前尝试向编译器解释什么是可能的，什么是不可能的，但可以说，我也可能在破解汇编程序之前尝试goto。

我遇到过goto是一个很好的解决方案的情况，我在这里或其他地方都没有看到过这个例子。

我有一个开关的情况下，所有的情况都需要调用相同的函数在最后。我有其他的情况，最后都需要调用不同的函数。

这看起来有点像这样:

switch( x ) {
    
    case 1: case1() ; doStuffFor123() ; break ;
    case 2: case2() ; doStuffFor123() ; break ;
    case 3: case3() ; doStuffFor123() ; break ;
    
    case 4: case4() ; doStuffFor456() ; break ;
    case 5: case5() ; doStuffFor456() ; break ;
    case 6: case6() ; doStuffFor456() ; break ;
    
    case 7: case7() ; doStuffFor789() ; break ;
    case 8: case8() ; doStuffFor789() ; break ;
    case 9: case9() ; doStuffFor789() ; break ;
}

我没有给每个case一个函数调用，而是用goto代替了break。goto跳转到一个标签，这也是在开关的情况下。

switch( x ) {
    
    case 1: case1() ; goto stuff123 ;
    case 2: case2() ; goto stuff123 ;
    case 3: case3() ; goto stuff123 ;
    
    case 4: case4() ; goto stuff456 ;
    case 5: case5() ; goto stuff456 ;
    case 6: case6() ; goto stuff456 ;
    
    case 7: case7() ; goto stuff789 ;
    case 8: case8() ; goto stuff789 ;
    case 9: case9() ; goto stuff789 ;
    
    stuff123: doStuffFor123() ; break ;
    stuff456: doStuffFor456() ; break ;
    stuff789: doStuffFor789() ; break ;
}

案例1到3都必须调用doStuffFor123()，类似的案例4到6必须调用doStuffFor456()等。

在我看来，如果你正确使用它们，gotos是非常好的。最后，任何代码都像人们写的那样清晰。有了gotos，你可以写出意大利面代码，但这并不意味着gotos是意大利面代码的原因。这个事业就是我们;程序员。如果我愿意，我也可以用函数创建意大利面条代码。宏也是如此。

这些年来，我写了不少汇编语言。最终，每一种高级语言都被编译成gotos。好吧，叫它们“分支”或“跳跃”或其他什么，但它们是gotos。有人能写无goto汇编器吗?

当然，你可以向Fortran、C或BASIC程序员指出，gotos的泛滥就像意大利肉酱面一样。然而，答案不是避免它们，而是小心地使用它们。

刀可以用来准备食物，解救某人，或者杀死某人。我们会因为害怕后者而没有刀吗?同样，“后向”:不小心使用它会碍事，小心使用它会有所帮助。

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