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

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

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

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

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

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

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

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

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

在一个完美的世界里，我们永远不需要GOTO。然而，我们生活在一个不完美的世界。我们并没有包含我们所能想到的所有控制结构的编译器。有时我觉得使用GOTO比拼凑一个并不存在的控制结构更好。

最常见的(并不是说它很常见)是循环半结构。你总是执行第一部分，也许你执行剩下的部分，然后返回，再执行第一部分。当然，你可以在while循环中使用布尔标记来实现它，但我不喜欢这个答案，因为在我看来它不太清楚。当你看到这样的东西:

loop:
  GetSomeData;
  if GotData then
     Begin
        ProcessTheData;
        StoreTheResult;
        Goto Loop;
     End;

对我来说，这比

Repeat
  GetSomeData;
  Flag := GotData;
  if Flag then
    Begin
      ProcessTheData;
      StoreTheResult;
    End;
Until Not Flag;

有些时候

Function GotTheData;

Begin
  GetSomeData;
  Result := GotData;
End;

While GotTheData do
  Begin
    ProcessTheData;
    StoreTheResult;
  End;

不是一个可行的答案，我坚信代码应该是清晰的。如果我必须做一个注释来解释代码在做什么，我会考虑是否可以让代码更清晰，并去掉注释。

被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中编程了一段时间)。

您可以使用它来打破深度嵌套循环，但大多数情况下，无需深度嵌套循环，代码可以重构得更干净。

今天，很难看出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运动的由来。