编辑：简介

为了吸引更广泛的读者，我通过一个复杂的（有点乏味的）现实生活中的例子重新阐述了我最初的问题。原始问题如下（远）所示。

Tom 刚刚被 Acme Inc. 聘为初级软件工程师（取决于他前两个工作日的表现）。他的工作是用编程语言 Acme++ 实现由高级软件开发人员设计的算法。公司严格遵循“不goto”政策由首席执行官独家命令。如果汤姆在试用期内表现出色，他将获得公司的全职工作。

第一天，Tom 收到了要实现的以下算法。

Step 1. START
Step 2. Input x
Step 3. In case x<0 goto Step 4 otherwise goto Step 5
Step 4. Set x=-x
Step 5. Output x
Step 6. END

汤姆觉得这个任务非常复杂，他认为研究程序的抽象结构（将其表示为流程图）会让他受益匪浅。画完后如下图第一天流程图他很快意识到，他被要求计算 x 的绝对值，并且他可以使用简单的 if-then-else 语句来实现它。汤姆很高兴，今天结束时他完成了任务。

第 2 天，Tom 收到了要实现的以下算法。

Step 1. START
Step 2. Input x
Step 3. In case x<0 goto Step 2 otherwise goto Step 4
Step 4. Output x
Step 5. END

Tom作为一个新手，再次觉得以抽象的方式来理解算法会更好，所以他画了下面的流程图第二天流程图.

检查流程图表明 Tom 被要求实现一个 while 循环，等待第一个非负输入。汤姆很高兴，并在一天结束时完成了他的任务。

基于汤姆的出色表现，他被公司聘用。

然而，在第 3 天，Tom 陷入了困境，因为他收到了 1996 的 1000 行算法goto跳跃是由该公司的一名前员工设计的，没有其他人知道该算法的作用、它是如何实现的以及为什么首先要以这种方式设计。然而，这根本不关心汤姆，因为他的唯一任务是实现算法，无论它是什么。凭借前两天的专业知识，他在 1000 个节点上绘制了具有 1997 个有向边的流程图。汤姆非常绝望，在 stackoverflow 上询问到底要怎么处理这么混乱的情况，经验丰富的程序员反复建议他

1. 将程序分解成更小的部分；和
2. 他确信在某些情况下实际上可以使用goto; and
3. 他被告知要“重组”该计划。

汤姆非常勤奋地考虑了这些建议，他的想法如下：

1. 他意识到，如果流图的连通分量恰好有一个入度和一个出度，那么就可以将其视为一种可以独立开发的“子算法”，因此他可以分解他的任务以这种方式。然而，他一开始就不知道如何找到这些组件，也不知道是否有其他智能方法可以进一步解决这个问题。
2. 汤姆并不真正关心是否使用goto是好的还是坏的编程实践（参见GOTO 仍然被视为有害吗？），他担心的是他的公司有一些他需要始终遵循的编程准则。
3. 汤姆确实可以触及算法，因为他可以自行决定替换某些指令，从而产生等效的算法。然而，汤姆不知道程序的哪一部分需要重组，更重要的是，他不明白为什么需要重组。 Tom 紧张地盯着他的 1000 个顶点图，一开始并不知道如何开始实现它。

关于这篇（编辑过的）帖子的问题如下：

你能帮助汤姆弄清楚如何开始实现一些不“两行死显而易见”的东西吗？特别是，应该以什么顺序执行流程图节点所描述的任务，这一点是否清楚？是否清楚某些嵌套循环应按什么顺序依次出现？

流程图中不能进一步分解成更小的部分的最小“原子”是什么？也就是说，Tom 什么时候才能自信地回应 stackoverflow“我已经将我的算法分解成更小的部分了”？一切本质上都是一个 while 循环和/或一个二进制分支点（第一天和第二天的任务），这是真的吗？

如何自动实现这样一个“原子”，或多或少以与汤姆在第一天和第二天所做的相同的方式？

汤姆可以与首席执行官争论使用goto在某些情况下是必不可少的，也就是说，要么他们用它来实现某种算法，要么根据公司的指导方针（即不使用goto)?

流程图的哪些部分存在问题并需要重组，为什么？例如，三路分支可以替换为嵌套的两路 if-then-else 语句，也就是说，Tom 可以安全地假设流程图上的每个节点的出度最多为 2。但是还应该进行哪些其他重组来处理由goto声明？什么样的图形属性使得重组成为必要？或许，学历高？

最初提出的算法（由软件开发团队）的流程图背后的数学（图）理论是什么，以及算法的重组和分解的流程图，哪个（比如汤姆）实际上更重要-或更少自动地实施？

原问题

假设我有一些使用二元决策的算法goto声明。该算法以以下高级方式描述为 N>=2（有限）步骤，并且应该按顺序执行（一个步骤接着一个步骤）：

任何算法

Step 1. START
Step 2. Do something. If condition in Step 2 holds goto Step X else goto Step Y.
Step 3. Do something. If condition in Step 3 holds goto Step U else goto Step V.
Step 4. Do something.
Step 5. Do something. If condition in Step 5 holds goto...
Step 6. ...
...
Step N. END

你明白了。例如，Knuth 在他的书中以这种独立于编程语言的高级方式描述了算法。

现在的问题是如何将这样的高级描述转换为goto语句到带有 while 循环和 if/else 语句的实际实现中？是否可以完全消除所有goto语句，并用 while 循环替换它们？如果是这样，应该如何做一般来说?

基于算法的描述，可以构建相应的流程图，从而构建（有向）流程图。所以换句话说，问题是“如何根据流程图实现代码而不需要goto声明一般来说?".

有两种方法可以回答这个问题。优选地，并且非常希望，我正在寻找一种算法方法来实现任何算法。如果算法是什么very简单，那么直观上就很清楚应该做什么，但在我看来，一旦频繁访问某个步骤（那里有很多 goto 语句跳转），或者换句话说，当其中一个节点时，事情就会变得相当复杂。流图的入度很大。然后我不太明白 while 循环应该以什么特定顺序嵌套。另一方面，很可能一个人根本无法做我想做的事情，这样的答案应该得到对算法不可能的高级描述的支持，该描述清楚地表明无论如何，一个人根本无法做到避免使用goto在实际实施中跳跃。

在我看来，将实现转换为流程图已被多次询问：自动流程图工具和这里创建流程图的算法[一点指导？？]。该程序代码2流似乎是可视化代码的一个很好的起点。

然而，在这里我对另一个方向感兴趣。简单的搜索发现DRAKON（也可以看看https://en.wikipedia.org/wiki/DRAKON and http://drakon-editor.sourceforge.net/）可能正在做我所要求的事情。从这个角度来看，问题是，这样一个自动流程图到代码程序在不使用goto陈述？

引用OP：最好并且很有希望，我正在寻找一种算法方法来实现任何算法

嗯，显而易见的答案是用目标语言为算法的每个步骤定义一个标签，在该标签处为每个步骤编写代码，并完全按照算法所描述的方式插入 GOTO 语句。这将为您提供一个大多数人称之为“意大利面条代码”的工作程序。

OP 有一个冗长的介绍，表明他（或者汤姆）更愿意以一种令人信服地匹配算法的方式编写一个无 goto 的版本。

好的，好消息是博姆和约科皮尼很久以前就表明，您可以仅使用以下三个基本控制流操作来实现任何计算sequence, 如果-那么-否则, and while 循环，具有单进单出的良好特性。所以我们知道有一个“结构化程序”的实现。

不太好的消息是，他们的构造性证明（从 gotoful/流程图版本构建此类程序的过程）引入了一组布尔变量和额外的测试来控制循环。这些变量用于跳过循环迭代的剩余部分，强制退出循环，并告诉循环调用者循环已退出。这个额外的 对我来说，即使您不反对管理这些变量所需的存储和执行时间，代码也会使生成的程序难以阅读。 （有关为 goto-ful COBOL 程序执行此操作的算法，请参阅维基百科链接）。

更好的消息是，S. Rao Kosaraju 证明，如果您可以跳出任意嵌套深度的循环，则无需额外的控制变量即可构建此类程序。许多编程语言都提供这样的功能； C 提供了一个带有“break N;”的脆弱版本。打破N个嵌套循环的语句[使用这个著名的东海岸AT&T电话系统崩溃事件，当时有人在现有代码中插入了一个额外的循环并且没有注意到break语句]。 Ada 和其他语言允许对循环进行标记，并且本质上是“离开”以使用指定的标签名称离开循环。对我来说，这是一个很好的解决方案。 [我更喜欢一种变体，其中有一个可以“离开”的标记开始结束块。 如果您的语言没有这样的带标签的离开结构，但您愿意以风格上认可的方式（而不是临时方式）使用 GOTO 语句，则可以通过放置标签来模拟离开语句after每个循环并写“goto”而不是leave。

因此，我们知道可以从任意干净的流程图/gotoful 程序中构建结构化程序。

遵循 Sue Graham 1975 年论文的思路，通过将原始流程图简化为结构化子元素来实现此目的的算法，用于全局流分析的快速且通常为线性的算法.

该算法的本质是在可能的情况下将原始流程图逐步简化为 Bohm/Jacopini 原语（序列/if-then-else/循环）构造，并减少“不可简化”构造（想想流程图中的一个小结） ）看起来不像这些特殊的方式。在每个步骤中，流程图的一部分都会简化为该部分的单个摘要节点。最终，这个过程将任意复杂度的原始流程图简化为单个节点。此时，缩减过程可以反向运行，每个汇总节点都扩展回原来的状态。

出于 OP 的目的，摘要节点的扩展提供了以结构化方式为简化子图编写代码的机会。重复直到生成原始流程图，然后导致整个程序以结构化方式编写。

【今天就这些了。让我们看看我是否可以产生一个算法。关注此空间]。