每个人都知道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。

计算现代C程序中goto的数量。现在添加break、continue和return语句的数量。此外,加上你使用if、else、while、switch或case的次数。这是1968年Dijkstra写这封信时,如果你用FORTRAN或BASIC语言编写程序,你的程序会有多少个goto。

当时的编程语言缺乏控制流程。例如,在最初的达特茅斯BASIC中:

IF statements had no ELSE. If you wanted one, you had to write: 100 IF NOT condition THEN GOTO 200 ...stuff to do if condition is true... 190 GOTO 300 200 REM else ...stuff to do if condition is false... 300 REM end if Even if your IF statement didn't need an ELSE, it was still limited to a single line, which usually consisted of a GOTO. There was no DO...LOOP statement. For non-FOR loops, you had to end the loop with an explicit GOTO or IF...GOTO back to the beginning. There was no SELECT CASE. You had to use ON...GOTO.

因此,您的程序中最终出现了许多goto。并且您不能依赖于goto限制在单个子例程中(因为GOSUB…RETURN是一个非常弱的子例程概念),所以这些goto可以去任何地方。显然,这使得控制流难以遵循。

这就是反goto运动的由来。

其他回答

并不是说去做本身不好;而是当同样的逻辑可以用另一种方式更清楚地表达时,使用goto是不好的。它会使代码很难遵循,也会使维护变得困难。以《糟糕的过去》中的一些Basic程序为例。

在我看来,在像c#这样的现代语言中,我们不应该在正常情况下需要goto。如果我发现自己正在使用它,这通常表明我需要重新思考我的逻辑——几乎肯定有一种更清晰的方式来使用正常的代码流语句来表达相同的代码。

也就是说,对于某些特殊的目的来说,goto是非常有用的(我发现自己对那些没有goto的语言非常恼火)。我主要在C语言中使用它来打破多层循环,或者进行错误处理;我相信c#的语言特性意味着您不必这样做。(它在生成自动生成代码时也非常有用,但大多数人在现实生活中不会遇到这种情况。)

goto还有一个纯粹的政治问题:很多人讨厌它,在代码中使用它,即使是合理的,也可能会引起问题。如果这是作业代码,那么是的,重写它,否则你可能会被扣分。否则,我倾向于把它留在那里,直到下次你需要对那部分进行维护。

原论文应该被认为是“无条件GOTO被认为是有害的”。它特别提倡一种基于条件(if)和迭代(while)结构的编程形式,而不是早期代码常见的测试-跳转。Goto在某些语言或环境中仍然有用,因为这些语言或环境不存在适当的控制结构。

从这里的任何答案中我都没有看到的一件事是,“去”解决方案通常比经常提到的结构化编程解决方案更有效。

考虑多嵌套循环的情况,其中使用'goto'而不是一堆if(breakVariable)节显然更有效。“将循环放入函数并使用return”的解决方案通常是完全不合理的。在循环可能使用局部变量的情况下,现在必须通过函数参数传递它们,可能会处理由此产生的额外麻烦。

现在考虑一下清理情况,我自己经常使用这种情况,而且这种情况非常常见,可能是try{} catch{}结构在许多语言中都不可用的原因。完成相同任务所需的检查和额外变量的数量远比完成跳转所需的一两个指令要糟糕得多,而且,额外的函数解决方案根本不是解决方案。你不能告诉我这更容易管理或更易于阅读。

现在,代码空间、堆栈使用和执行时间在许多情况下对许多程序员来说可能还不够重要,但当您在一个只有2KB代码空间的嵌入式环境中工作时,为了避免一个明确定义的“goto”而额外执行50字节的指令是可笑的,而且这种情况并不像许多高级程序员所认为的那样罕见。

“goto有害”这句话对迈向结构化编程非常有帮助,即使它总是一种过度概括。在这一点上,我们都听到了足够多的使用它的谨慎(我们应该)。当它显然是工作的正确工具时,我们不需要害怕它。

没有所谓的GOTO被认为是有害的。

GOTO是一种工具,和所有工具一样,它可以被使用和滥用。

然而,在编程世界中有许多工具倾向于被滥用而不是被使用,GOTO就是其中之一。Delphi的WITH语句是另一个。

就我个人而言,我在典型的代码中不使用这两种方法,但我有过GOTO和WITH的奇怪用法,这是有保证的,另一种解决方案将包含更多的代码。

最好的解决方案是编译器只警告你关键字被污染了,你必须在语句周围塞几个pragma指令来消除警告。

这就像告诉你的孩子不要拿着剪刀跑。剪刀并不坏,但使用它们可能不是保持健康的最佳方式。

几乎所有可以使用goto的情况,都可以使用其他结构实现相同的效果。无论如何,编译器都会使用Goto。

我个人从来没有明确地使用它,也不需要。