关于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:

例子:

    // 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中，使用标签从循环中“goto”—使用“last”语句，这类似于break。

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

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

Everybody who is anti-goto cites, directly or indirectly, Edsger Dijkstra's GoTo Considered Harmful article to substantiate their position. Too bad Dijkstra's article has virtually nothing to do with the way goto statements are used these days and thus what the article says has little to no applicability to the modern programming scene. The goto-less meme verges now on a religion, right down to its scriptures dictated from on high, its high priests and the shunning (or worse) of perceived heretics.

让我们把Dijkstra的论文放在背景中，对这个问题有一些了解。

When Dijkstra wrote his paper the popular languages of the time were unstructured procedural ones like BASIC, FORTRAN (the earlier dialects) and various assembly languages. It was quite common for people using the higher-level languages to jump all over their code base in twisted, contorted threads of execution that gave rise to the term "spaghetti code". You can see this by hopping on over to the classic Trek game written by Mike Mayfield and trying to figure out how things work. Take a few moments to look that over.

这就是Dijkstra在1968年的论文中谴责的“毫无节制地使用go to语句”。这就是他所生活的环境，促使他写出了那篇论文。在你的代码中，在你喜欢的任何地方跳转的能力是他所批评和要求停止的。将其与C或其他更现代的语言中goto的弱功能进行比较简直是可笑的。

我已经能听到信徒们面对异教徒时扬起的呐喊声了。“但是，”他们会念叨，“用c语言的goto会让代码变得很难读。”哦,是吗?如果没有goto，代码也会变得难以阅读。比如这个:

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
        _-_-_-_-_-_-_-_
            _-_-_-_
}

看不见goto，所以它一定很容易读，对吧?或者这个怎么样:

a[900];     b;c;d=1     ;e=1;f;     g;h;O;      main(k,
l)char*     *l;{g=      atoi(*      ++l);       for(k=
0;k*k<      g;b=k       ++>>1)      ;for(h=     0;h*h<=
g;++h);     --h;c=(     (h+=g>h     *(h+1))     -1)>>1;
while(d     <=g){       ++O;for     (f=0;f<     O&&d<=g
;++f)a[     b<<5|c]     =d++,b+=    e;for(      f=0;f<O
&&d<=g;     ++f)a[b     <<5|c]=     d++,c+=     e;e= -e
;}for(c     =0;c<h;     ++c){       for(b=0     ;b<k;++
b){if(b     <k/2)a[     b<<5|c]     ^=a[(k      -(b+1))
<<5|c]^=    a[b<<5      |c]^=a[     (k-(b+1     ))<<5|c]
;printf(    a[b<<5|c    ]?"%-4d"    :"    "     ,a[b<<5
|c]);}      putchar(    '\n');}}    /*Mike      Laman*/

也不去那里。因此它必须是可读的。

我举这些例子的重点是什么?并不是语言特性导致代码不可读、不可维护。这不是语法造成的。这是糟糕的程序员造成的。而糟糕的程序员，正如你在上面的项目中所看到的，可以使任何语言特性无法阅读和使用。比如上面的for循环。(你能看到他们，对吧?)

公平地说，有些语言结构比其他结构更容易被滥用。然而，如果你是一个C程序员，我会更仔细地观察#define大约50%的使用情况，然后才会开始反对goto!

因此，对于那些已经阅读到这里的人来说，有几个关键点需要注意。

Dijkstra's paper on goto statements was written for a programming environment where goto was a lot more potentially damaging than it is in most modern languages that aren't an assembler. Automatically throwing away all uses of goto because of this is about as rational as saying "I tried to have fun once but didn't like it so now I'm against it". There are legitimate uses of the modern (anaemic) goto statements in code that cannot be adequately replaced by other constructs. There are, of course, illegitimate uses of the same statements. There are, too, illegitimate uses of the modern control statements like the "godo" abomination where an always-false do loop is broken out of using break in place of a goto. These are often worse than judicious use of goto.

我发现do{} while(false)的用法完全令人反感。它可能会让我相信它在某些奇怪的情况下是必要的，但从来没有让我相信它是干净合理的代码。

如果必须执行这样的循环，为什么不显式地依赖标志变量呢?

for (stepfailed=0 ; ! stepfailed ; /*empty*/)

我发现有趣的是，有些人会给出一个可以接受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有用的例子，而轻视任何你想不到的好例子。