構造化定理
↑ なお、goto文を除去した構造化したプログラムは、必ずしも良いデザインのプログラムになることを保証しない。ミルズらによれば、良いデザインは単純な考えに基づいているのではなく、奥深い簡潔さに基づくものである。
↑ なお、ここで主張されている「正当化」とは、全く同じ計算をすることを理論的に保証するという意味であり、そのように人間がプログラムを書くべきという意味ではない。たとえば近年よく使われている難読化ツール(obfuscator)がプログラムを難読化することも全く同様に「正当化」できるが、そのように人間がプログラムを書くべきという意味ではない。
1 2 3 4 5 ここで言う構造化プログラミングは、エドガー・ダイクストラの構造化プログラミングではない。構造化定理を使ったプログラミングの意味である。
f : N n → N {\displaystyle f\colon \mathbb {N} ^{n}\to \mathbb {N} } をフローチャートによって計算可能な(一般には部分的に定義された)関数とする。これは再帰的関数になっている。クリーネの標準形定理(の弱い形)によれば、原始再帰的関数 T : N n + 1 → { 0 , 1 } {\displaystyle T\colon \mathbb {N} ^{n+1}\to \{0,1\}} と U : N → N {\displaystyle U\colon \mathbb {N} \to \mathbb {N} } が存在して、
f ( x → ) = U ( min { y ∈ N | T ( x → , y ) = 1 } ) {\displaystyle f({\vec {x}})=U(\min\{y\in \mathbb {N} |T({\vec {x}},y)=1\})}
が成り立つ。
ベーム-ヤコピーニの証明は、プログラムを改良するよりもプログラムを不明瞭にする可能性が高かったので、ソフトウェア開発のために構造化プログラミングを採用するかどうかという疑問を解決しなかった。
それどころか議論の始まりを告げることになった。エドガー・ダイクストラの有名な文書「Go To Statement Considered Harmful(英語版)(Go to 文は有害と考えられる)」は1968年にその議論に続いた。
幾人かの研究者はベーム-ヤコピーニの結論に対して純粋な手段を取った。そして、ループの途中にある break と return ですらベーム-ヤコピーニの証明に必要とされていないので悪い実践であると主張した。したがって全てのループは単一の脱出ポイントを持つべきだと主張した。この純粋な手段はPascalプログラミング言語(1968~1969に設計)で具体化された。Pascalは1990年代中頃まで大学の入門的なプログラミングの講義をするために好まれたツールであった。
エドワード・ヨードンは、構造化プログラミングの流行が始まった時からの議論に基づいて、1970年代に非構造化プログラムを機械的に構造化プログラムに変換することに哲学的な反対があったと述べている。実用本位の対照的なこととして、そのような変換が既存のプログラムの大きなコードに役立ったということもあった。機械的変換のための最初の提案の一つは、エドワード・アッシュクロフト(Edward Ashcroft)とゾハル・マンナ(英語版)(Zohar Manna)による1971年の論文であった。