转到被视为有害的声明？

Question

如果上面的说法是正确的，那么为什么当我在 .Net BCL 上使用反射器时，我看到它被大量使用？

编辑：让我重新表述一下：我在反射器中看到的所有 GO-TO 都是由人类或编译器编写的吗？

Answer 1

我认为以下关于 Goto 的维基百科文章的摘录在这里特别相关：

可能是最著名的批评
GOTO 是 Edsger 于 1968 年写的一封信
Dijkstra 调用 Go To 语句
被认为是有害的。在那封信中
Dijkstra 认为不受限制的 GOTO
声明应被废除
高级语言，因为它们
使分析和分析任务变得复杂
验证程序的正确性
（特别是那些涉及循环的）。
提出了另一种观点
在唐纳德·高德纳 (Donald Knuth) 的《结构化》中
使用 go to 语句进行编程
分析了许多常见的编程
任务并发现其中一些
GOTO 是最佳语言结构
使用。

因此，一方面，我们有Edsger Dijkstra（一位非常有才华的计算机科学家）争论< em>反对使用GOTO语句，特别反对过度使用GOTO语句，理由是：这是一种不太结构化的代码编写方式。

另一方面，我们有 Donald Knuth（另一位非常有才华的计算机科学家）认为使用 GOTO，特别是明智地使用它实际上可以成为给定的程序代码片段的“最佳”和最优化的构造。

最终，恕我直言，我相信这两个人都是正确的。 Dijkstra 的观点是正确的，过度使用GOTO 语句肯定会降低一段代码的可读性和结构性，从纯理论角度看待计算机编程时确实如此。

然而，Knuth 也是正确的，因为在“现实世界”中，人们必须采取务实的方法，明智地使用 GOTO 语句确实可以成为最佳选择要使用的语言构造。

Answer 2

上面的内容并不完全正确 - 它是 Dijkstra 在 gotos 时使用的一种争论手段是唯一正在使用的流量控制结构。事实上，已经有几个人提出了反驳，包括 Knuth 的经典论文《StructuredProgrammingUsingGoto》（标题凭记忆）。在某些情况下（错误处理、状态机），goto 可以生成比“结构化”替代方案更清晰的代码（恕我直言）。

Answer 3

这些 goto 通常是由编译器生成的，尤其是在枚举器内部。
编译器总是知道她在做什么。

如果您发现自己需要使用 goto，您应该确保它是唯一的选择。大多数情况下，您会发现有更好的解决方案。

除此之外，在极少数情况下使用 goto 是合理的，例如使用嵌套循环时。同样，在这种情况下还有其他选择。您可以打破函数中的内部循环并使用 return 语句代替。您需要仔细查看额外的方法调用是否真的成本太高。

---

响应您的编辑：

不，并非所有 goto 都是编译器生成的，但其中很多是由编译器生成的状态机（枚举器）、switch case 语句或优化的 if else 结构产生的。只有少数情况下您才能判断是编译器还是原始开发人员造成的。您可以通过查看函数/类名称来获得良好的提示，编译器将生成“禁止”名称以避免与您的代码发生名称冲突。如果一切看起来正常并且代码尚未优化或混淆，则可能打算使用 goto。

Answer 4

请记住，您在 Reflector 中看到的代码是反汇编代码——Reflector 正在查看编译后的字节代码并尝试将原始源代码拼凑在一起。

因此，您必须记住，针对 goto 的规则适用于高级代码。用于替换 goto 的所有结构（for、while、break、switch< /code> 等）都使用 JMP 编译为代码。

因此，Reflector 像这样看待代码：

A:
    if !(a > b)
        goto B;
    DoStuff();
    goto A;
B:  ...

并且必须意识到它实际上被编码为：

 while (a > b)
    DoStuff();

有时读取的代码太复杂而无法识别模式。

Answer 5

Go To 语句本身并无害处，有时甚至非常有用。有害的是那些倾向于将其放在代码中不适当位置的用户。

Answer 6

当编译为汇编代码时，所有控制都会结构化并转换为（非）条件跳转。然而，优化器可能太强大了，当反汇编器无法识别跳转模式对应的控制结构时，就会发出始终正确的语句，即goto label;。

这与goto 的危害性无关。

Answer 7

例如，双循环或许多嵌套循环（您已突破其中的循环）怎么样？

 foreach (KeyValuePair<DateTime, ChangedValues> changedValForDate in _changedValForDates)
            {
                foreach (KeyValuePair<string, int> TypVal in changedValForDate.Value.TypeVales)
                {
                    RefreshProgress("Daten werden geändert...", count++, false);

                    if (IsProgressCanceled)
                    {
                        goto TheEnd; //I like goto :)
                    }
                }
            }
TheEnd:

在这种情况下，您应该考虑使用中断来完成以下操作：

  foreach(KeyValuePair<DateTime, ChangedValues> changedValForDate in _changedValForDates)
    {
                    foreach (KeyValuePair<string, int> TypVal in changedValForDate.Value.TypeVales)
                    {
                        RefreshProgress("Daten werden geändert...", count++, false);

                        if (IsProgressCanceled)
                        {
                            break; //I miss goto :|
                        }
                    }

                 if (IsProgressCanceled)
                 {
                            break; //I really miss goto now :|
                 }//waaaAA !! so many brakets, I hate'm
    }

Answer 8

一般规则是您不需要使用goto。与任何规则一样，当然也有例外，但与任何例外一样，例外情况很少。

goto 命令就像毒品。如果仅在特殊情况下限量使用，那就很好。如果你一直使用太多，它会毁掉你的生活。

当您使用 Reflector 查看代码时，您看不到实际的代码。您看到的代码是根据编译器从原始代码生成的代码重新创建的。当您在重新创建的代码中看到 goto 时，并不确定原始代码中是否存在 goto。可能有一个更结构化的命令来控制流程，例如 break 或 continue，编译器以与 goto< 相同的方式实现/code>，这样 Reflector 就无法区分。

Answer 9

goto 被认为有害（人类使用但
对于计算机来说还可以）。

因为无论我们（人类）多么疯狂地使用 goto，编译器总是知道如何阅读代码。

相信我...

使用 goto 阅读其他代码其中的 code> 很难。
阅读自己的带有 goto 的代码更加困难。

这就是为什么你看到它用于低级（机器语言）而不是高级（人类语言，例如 C#、Python...）；）

Answer 10

“C 提供了无限滥用的 goto 语句和分支标签。从形式上来说，goto 从来都不是必需的，而在实践中，没有它几乎总是很容易编写代码。我们还没有使用 goto在这本书里。”

-- K&R（第二版）：第 65 页

Answer 11

当我想执行终止操作时，我有时会使用 goto：

static void DoAction(params int[] args)
{
  foreach (int arg in args)
  {
    Console.WriteLine(arg);
    if (arg == 93) goto exit;
  }

  //edit:
  if (args.Length > 3) goto exit;
  //Do another gazillion actions you might wanna skip.

  //etc.
  //etc.

exit:
  Console.Write("Delete resource or whatever");
}

因此，我不是按 return，而是将其发送到执行另一个最终操作的最后一行，我可以从代码片段中的各个位置引用，而不是刚刚终止。

Answer 12

在反编译的代码中，几乎所有您看到的 goto 都是合成的。不用担心他们；它们是如何在低级别表示代码的产物。

至于将它们放入您自己的代码中的正当理由吗？我能想到的主要问题是您使用的语言没有提供适合您正在解决的问题的控制结构；可以轻松创建自定义控制流系统的语言通常根本没有 goto 。完全避免使用它们也总是可能的，但是将任意复杂的代码重新排列到一个 while 循环和大量带有一整套控制变量的条件中......这实际上会使代码变得更加晦涩难懂（而且速度也较慢；编译器通常不够聪明，无法区分这种复杂性）。编程的主要目标应该是生成对计算机和阅读程序的人来说都清晰的程序描述。

Answer 13

有害与否，就看各人的喜好了。我个人不喜欢它们，并且发现它们在尝试代码的可维护性时效率很低。

现在，一件事是 goto 如何影响我们对代码的阅读，而另一件事是找到 goto 时抖动如何执行。来自 Eric Lippert 的博客，我想引用一下：

我们首先运行一次将循环转换为 goto 和标签。

因此，实际上编译器在发出 IL 时将几乎每个流控制结构转换为 goto/label 模式。当反射器读取程序集的 IL 时，它会识别该模式，并将其转换回适当的流控制结构。

在某些情况下，当发出的代码对于反射器来说太复杂而无法理解时，它只会向您显示使用标签和 goto 的 C# 代码，相当于它正在读取的 IL。例如，使用 yield return 和 yield break 语句实现 IEnumerable 方法时就是这种情况。这些类型的方法使用底层状态机转换为它们自己的实现 IEnumerable 接口的类。我相信在BCL你会发现很多这样的案例。

Answer 14

如果没有如上所述过度使用，GOTO 可能会很有用。 Microsoft 甚至在 .NET Framework 本身的多个实例中使用它。

Answer 15

这些 goto 通常由编译器生成，尤其是在枚举器内部。编译器总是知道她在做什么。

如果您发现自己需要使用 goto，您应该确保它是唯一的选择。大多数情况下，您会发现有更好的解决方案。

除此之外，很少有情况可以证明使用 goto 是合理的，例如使用嵌套循环时。同样，在这种情况下还有其他选择。您可以打破函数中的内部循环并使用 return 语句代替。您需要仔细查看额外的方法调用是否真的成本太高。