每个人都知道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就像台锯,在采取适当的安全措施时非常有用。

我认为这是有害的,因为大多数初学者都失去了桌子锯和goto的手指。

在某些情况下,这是控制心流的唯一方法,但这些情况是可以避免的。

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

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

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

Since I began doing a few things in the linux kernel, gotos don't bother me so much as they once did. At first I was sort of horrified to see they (kernel guys) added gotos into my code. I've since become accustomed to the use of gotos, in some limited contexts, and will now occasionally use them myself. Typically, it's a goto that jumps to the end of a function to do some kind of cleanup and bail out, rather than duplicating that same cleanup and bailout in several places in the function. And typically, it's not something large enough to hand off to another function -- e.g. freeing some locally (k)malloc'ed variables is a typical case.

I've written code that used setjmp/longjmp only once. It was in a MIDI drum sequencer program. Playback happened in a separate process from all user interaction, and the playback process used shared memory with the UI process to get the limited info it needed to do the playback. When the user wanted to stop playback, the playback process just did a longjmp "back to the beginning" to start over, rather than some complicated unwinding of wherever it happened to be executing when the user wanted it to stop. It worked great, was simple, and I never had any problems or bugs related to it in that instance.

Setjmp /longjmp有它们自己的位置——但那个位置是你不太可能只在很长一段时间内访问一次的地方。

编辑:我只是看了一下代码。实际上,我使用的是siglongjmp(),而不是longjmp(不是说这是一个大问题,但我已经忘记了siglongjmp的存在。)

因为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,“只是为了惹恼那些纯粹主义者”。