每个人都知道Dijkstra的《致编辑的信》:goto语句被认为是有害的(这里。html transcript和这里。pdf)，从那时起，就有一种强大的推动力，尽可能避免使用goto语句。虽然可以使用goto来生成不可维护的、庞大的代码，但它仍然存在于现代编程语言中。即使Scheme中先进的连续控制结构也可以被描述为复杂的后向。
在什么情况下需要使用goto?什么时候最好避免?
作为一个后续问题:C提供了一对函数setjmp()和longjmp()，它们不仅提供了在当前堆栈帧内进行跳转的能力，还提供了在任何调用帧内进行跳转的能力。这些应该被认为和goto一样危险吗?更危险?
Dijkstra自己也对这个头衔感到后悔，因为这不是他的责任。在EWD1308的结尾(也在这里。pdf)，他写道:
Finally a short story for the record.
In 1968, the Communications of the ACM
published a text of mine under the
title "The goto statement considered
harmful", which in later years would
be most frequently referenced,
regrettably, however, often by authors
who had seen no more of it than its
title, which became a cornerstone of
my fame by becoming a template: we
would see all sorts of articles under
the title "X considered harmful" for
almost any X, including one titled
"Dijkstra considered harmful". But
what had happened? I had submitted a
paper under the title "A case against
the goto statement", which, in order
to speed up its publication, the
editor had changed into a "letter to
the Editor", and in the process he had
given it a new title of his own
invention! The editor was Niklaus
Wirth.
Donald E. Knuth写了一篇关于这个主题的经典论文，它与Dijkstra的论文相匹配，那就是结构化编程与语句。阅读既有助于重建上下文，也有助于对主题的非教条性理解。在本文中，Dijkstra对这个案例的观点被报道，并且更加强烈:
Donald E. Knuth:我相信通过呈现这样一个
事实上，我并不是不同意
Dijkstra的观点，因为
他最近写道:
“请不要落入。
相信我是可怕的
教条的关于[去]的教条的
声明)。我觉得很不舒服
感觉别人在做
宗教出来了，好像
编程的概念问题
只用一个小技巧就能解决，用什么
一种简单的编码纪律!”
因为goto可以用于令人困惑的元编程
Goto既是高级控件表达式，也是低级控件表达式，因此它没有适合大多数问题的合适设计模式。
它是低级的，因为goto是一个基本操作，它实现了一些高级操作，比如while或foreach之类的。
从某种意义上说，它是高级的，当以某种方式使用时，它将以一种清晰的顺序执行的代码，以一种不间断的方式(除了结构化循环)，并将其转换为逻辑片段，这些逻辑片段有足够的gotos，可以动态地重新组装逻辑。
所以，有平淡的一面，也有邪恶的一面。
平淡的一面是，一个向上指向的goto可以实现一个完全合理的循环，而一个向下指向的goto可以执行一个完全合理的中断或返回。当然，实际的while、break或return语句可读性更强，因为可怜的人不需要为了了解全局而模拟goto语句的效果。总的来说，这是个坏主意。
The evil side involves a routine not using goto for while, break, or return, but using it for what's called spaghetti logic. In this case the goto-happy developer is constructing pieces of code out of a maze of goto's, and the only way to understand it is to simulate it mentally as a whole, a terribly tiring task when there are many goto's. I mean, imagine the trouble of evaluating code where the else is not precisely an inverse of the if, where nested ifs might allow in some things that were rejected by the outer if, etc, etc.
Finally, to really cover the subject, we should note that essentially all early languages except Algol initially made only single statements subject to their versions of if-then-else. So, the only way to do a conditional block was to goto around it using an inverse conditional. Insane, I know, but I've read some old specs. Remember that the first computers were programmed in binary machine code so I suppose any kind of an HLL was a lifesaver; I guess they weren't too picky about exactly what HLL features they got.
说了这么多，我曾经在我写的每个程序中都加了一个go，“只是为了惹恼那些纯粹主义者”。
被Jay Ballou添加的答案所吸引，我会加入0.02英镑。如果Bruno Ranschaert还没有这样做，我就会提到Knuth的“用GOTO语句进行结构化编程”的文章。
有一件事我没有看到讨论，那就是那种在Fortran教科书中教过的代码，尽管它并不常见。例如DO循环的扩展范围和开放代码子程序(记住，这将是Fortran II, Fortran IV或Fortran 66 -而不是Fortran 77或90)。至少有可能语法细节不准确，但概念应该足够准确。每种情况下的代码片段都在单个函数中。
请注意，由Kernighan和Plauger撰写的优秀但过时(并且绝版)的《编程风格的元素，第二版》中包含了一些来自那个时代(70年代末)编程教科书中滥用GOTO的现实例子。然而，下面的材料并不是来自那本书。
DO循环的扩展范围
do 10 i = 1,30
...blah...
...blah...
if (k.gt.4) goto 37
91 ...blah...
...blah...
10 continue
...blah...
return
37 ...some computation...
goto 91
One reason for such nonsense was the good old-fashioned punch-card. You might notice that the labels (nicely out of sequence because that was canonical style!) are in column 1 (actually, they had to be in columns 1-5) and the code is in columns 7-72 (column 6 was the continuation marker column). Columns 73-80 would be given a sequence number, and there were machines that would sort punch card decks into sequence number order. If you had your program on sequenced cards and needed to add a few cards (lines) into the middle of a loop, you'd have to repunch everything after those extra lines. However, if you replaced one card with the GOTO stuff, you could avoid resequencing all the cards - you just tucked the new cards at the end of the routine with new sequence numbers. Consider it to be the first attempt at 'green computing' - a saving of punch cards (or, more specifically, a saving of retyping labour - and a saving of consequential rekeying errors).
哦，你可能还注意到我在作弊，没有大喊大叫——Fortran IV通常都是大写的。
中非子例程
...blah...
i = 1
goto 76
123 ...blah...
...blah...
i = 2
goto 76
79 ...blah...
...blah...
goto 54
...blah...
12 continue
return
76 ...calculate something...
...blah...
goto (123, 79) i
54 ...more calculation...
goto 12
标签76和54之间的GOTO是计算GOTO的一个版本。如果变量i的值为1，则转到列表中的第一个标签(123);如果它的值是2，就转到秒，以此类推。从76到计算goto的片段是开放编码的子程序。它是一段执行起来很像子例程的代码，但写在函数体中。(Fortran也有语句函数——它们是嵌入在单行上的函数。)
还有比计算goto更糟糕的结构——你可以给变量赋标签，然后使用赋值的goto。google assigned goto告诉我它已经从Fortran 95中删除了。值得注意的是，结构化编程革命可以说是从Dijkstra的“GOTO被认为是有害的”信件或文章开始的。
如果不了解Fortran语言(以及其他语言，其中大多数已经半途而用了)中所做的事情，我们这些新手很难理解Dijkstra所处理的问题的范围。见鬼，直到那封信发表10年后，我才开始编程(但我确实不幸地在Fortran IV中编程了一段时间)。
Go To可以在某些情况下为“真正的”异常处理提供一种替代品。考虑:
ptr = malloc(size);
if (!ptr) goto label_fail;
bytes_in = read(f_in,ptr,size);
if (bytes_in=<0) goto label_fail;
bytes_out = write(f_out,ptr,bytes_in);
if (bytes_out != bytes_in) goto label_fail;
显然，这段代码被简化了，以占用更少的空间，所以不要太纠结于细节。但是考虑一下我在产品代码中多次看到的另一种选择，即程序员为了避免使用goto而费尽心机:
success=false;
do {
ptr = malloc(size);
if (!ptr) break;
bytes_in = read(f_in,ptr,size);
if (count=<0) break;
bytes_out = write(f_out,ptr,bytes_in);
if (bytes_out != bytes_in) break;
success = true;
} while (false);
现在这段代码在功能上做了完全相同的事情。事实上，编译器生成的代码几乎完全相同。然而，在程序员对Nogoto(可怕的学术指责之神)的热情中，这个程序员完全打破了while循环所代表的底层习惯，并对代码的可读性造成了实质性的影响。这样也好不到哪里去。
所以，这个故事的寓意是，如果你发现自己为了避免使用goto而求助于一些非常愚蠢的事情，那么就不要这样做。
