每个人都知道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的函数允许你在GOTO允许的范围内跳得更远,都应该被认为比GOTO更危险。

其他回答

许多现代编程语言使用它们的编译器来强制限制GOTO的使用——这减少了潜在的风险。例如,c#不允许您使用GOTO从循环体外部跳转到循环体。文档中提到了限制。

这是GOTO有时比过去更安全的一个例子。

在某些情况下,GOTO的使用与提前从函数返回相同(即提前跳出循环)。然而,良好的形式是有争议的。

在我看来,“goto有害”更多的是关于状态的封装和一致性。

许多代码,甚至是'oo'代码,都有像意大利面条代码一样糟糕的混乱状态封装。

“goto有害”的问题是,它让程序员只看机制规则而不理解这样的印象,即唯一可用的流控制应该是返回方法,这很容易导致通过引用传递许多状态——这又导致缺乏状态封装,而这正是“goto有害”试图摆脱的东西。

遵循典型的“OO”代码库中的控制流,并告诉我我们仍然没有意大利面条代码....(顺便说一下,我并不是指那些经常让人讨厌的“馄饨”代码——馄饨代码的执行路径通常是非常简单的,即使对象关系不是立即明显的)。

或者,换一种说法,避免gotos而将所有东西都作为子例程,只有在每个子例程只修改局部状态时才有用,只有通过该子例程(或至少该对象)才能修改局部状态。

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

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

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

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

goto有一些问题。一是很难看到代码是如何流动的。因为花括号,所以更容易看到if-block,但是goto隐藏了它。此外,while和if本质上也是goto,但它们有助于解释为什么要在代码中来回跳转。有了一个固定的目标,你必须自己拼凑起来。

作为练习,试着编写一些计算斐波那契数列的代码,看看当你完成后,它有多难阅读。

如果你要处理这些代码,那么我建议你写一些单元测试,然后重写它。否则,就顺其自然吧。

尽管如此,有时出于性能原因,使用goto“可能”是合适的。

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