# Go To Statement Considered Harmful > [!abstract] 概要 > 編集者へ： > 私は長年にわたり、プログラマの質は彼らが作成するプログラム中の goto 文の密度の減少関数であるという観察に親しんできた。より最近になって、私はなぜ goto 文の使用がこれほど壊滅的な影響を及ぼすのかを発見し、goto 文はすべての「高級」プログラミング言語（すなわち、おそらく純粋な機械語コードを除くすべて）から廃止されるべきであると確信するに至った。当時、私はこの発見にあまり重要性を認めていなかったが、最近の議論でこの主題が持ち上がった際にそうするよう強く促されたため、私の考察を出版のために提出する。 > 私の第一の指摘は、プログラマの活動は正しいプログラムを構築した時点で終了するものの、彼のプログラムの制御下で行われるプロセスこそが彼の活動の真の主題であるということだ。なぜなら、望ましい効果を達成しなければならないのはこのプロセスであり、その動的な振る舞いにおいて望ましい仕様を満たさなければならないのはこのプロセスだからである。しかし、ひとたびプログラムが作られると、対応するプロセスを「作ること」は計算機に委ねられる。 > 私の第二の指摘は、我々の知的能力は静的な関係を把握することにかなり適しているのに対し、時間の中で推移するプロセスを視覚化する能力は比較的貧弱にしか発達していないということだ。その理由から、我々は（自らの限界を自覚した賢明なプログラマとして）、静的なプログラムと動的なプロセスとの間の概念的な間隙を縮め、テキスト空間に広がるプログラムと時間空間に広がるプロセスとの間の対応関係を可能な限り自明なものにするよう、最善を尽くすべきである。 ## 論文情報 - 著者: [[Edsger W. Dijkstra]]（[[Eindhoven University of Technology]]） - 掲載: *Communications of the ACM* (CACM), Volume 11, Number 3, March 1968, Letters to the Editor, pp. 147–148. - DOI: 10.1145/362929.362947 ## 概要 本論文は、プログラミング言語における `goto` 文（無条件分岐命令）が無制御に用いられることで、静的なプログラムテキストと実行時に展開される動的プロセスとの間の概念的乖離が極限まで拡大し、プロセスの進行状況を追跡・理解することが極めて困難になる機序を指摘した歴史的書簡である。Dijkstra は、代入文の連接、条件分岐（if-then, if-then-else, case）、手続き呼び出し、反復節（while-repeat, repeat-until）といった制御構造を採用することにより、静的な「テキスト上の指標（textual index）」と実行時反復数を追跡する「動的指標（dynamic index）」の混合列という、プログラマの手から独立した座標系によってプロセスの動的進行が一意かつ把握可能に記述できることを示した。これに対し、goto 文の野放図な使用はこの座標系を破壊するため、高級言語から全面的に追放されるべきであると主張した。 ## 問題設定 プログラマの目標は正しいプログラムを作成することにあるが、真に対処すべき対象は実行時に計算機上で推移する「動的なプロセス」である。しかし、人間の認知能力は空間的・静的な関係の把握には優れているものの、時間軸に沿って展開する動的なプロセスの推移を追跡・想起する能力は極めて限定されている。 プログラムの正当性を理解・検証するためには、実行中のある任意の瞬間における変数の意味を解釈できなければならない。変数の値の意味（たとえば「部屋の中にいる人数 $n$」を数える際に、入場直後かつインクリメント前の瞬間では $n$ は「実際の人数引く1」を意味する）は、プロセスがどの地点まで進行したかという「進行座標」と相対的にしか確定できない。したがって、テキスト空間に広がる静的なプログラムと、時間空間に広がる動的なプロセスとの間の対応関係を極力シンプルかつ自明に保つことが、信頼できるソフトウェア構築の根幹的課題となる。 ## 提案手法 Dijkstra は、プロセス進行を把握・再現するために必要な「プログラマの作為から独立した座標系」の構築法を提示した。 1. **連接（Concatenation of assignments）**: 純粋な代入文の連接では、テキスト上の 2 つの文の間に置かれるポインタ（**テキスト指標 / textual index**）1 つだけでプロセスの進行が一意に定まる。テキスト空間での後続と時間空間での後続が完全に一致する。 2. **条件節・選択節（Conditional / Alternative / Choice clauses）**: `if B then A`、`if B then A1 else A2`、Hoare の `case [i] of (A1, ..., An)`、McCarthy の条件式 `(B1 -> E1, ..., Bn -> En)` を含めても、プロセスの進行は依然として単一のテキスト指標によって特徴づけられる。 3. **手続き呼び出し（Procedure calls）**: 手続き本体の内部を指す場合、単一の指標では不十分であり、呼び出しの動的深さに等しい長さを持つ「テキスト指標の列」によってプロセスの進行が表現される。 4. **反復節（Repetition clauses）**: `while B repeat A` や `repeat A until B` などの反復節は、論理的には再帰手続きで代替可能であるが、有限の計算機上での実装の容易性と「数学的帰納法（induction）」という人間の推論能力に適合することから不可欠である。反復節への突入ごとに、現在の反復回数を厳格に数え上げる「**動的指標（dynamic index）**」を対応づける。反復節や手続きがネストしても、プロセス進行はテキスト指標と動的指標の混合列として一意に特定される。 これらの指標の値はプログラマの主観的な制御の外側にあり、プログラムの記述とプロセスの動的推移によって自動的・客観的に生成される「独立した座標系」を形成する。 ## 新規性 従来のプログラミング実務において、goto 文はジャンプ命令として自然に受け入れられていた。これに対し Dijkstra は以下の点を明らかにした。 1. **静的テキストと動的プロセスの概念間隙の定式化**: goto 文の有害性を「コードの汚さ」という感覚論ではなく、「テキスト空間（静的構造）」と「時間空間（動的プロセス）」の間の同型写像を断絶させ、プロセスの進行を記述する有意味な独立座標系を喪失させる点にあると理論的に論証した。 2. **構造化された制御構造による座標系の回復**: 代入の連接、条件分岐、手続き、反復という限定された制御構造の組み合わせのみが、プログラマに知的把握可能性（intellectual grasp）を保証する座標系（テキスト指標列と動的指標列）を提供することを明示した。 3. **高級言語からの goto 文完全追放の提唱**: 機械語を除くすべての高級プログラミング言語から goto 文を撤廃すべきであるという明確な規範的方針を世界で初めて公に打ち出した。 ## 考察 - **正規化クロックの無力さ**: goto 文が存在するプログラムでも、開始からの総実行ステップ数を数えるカウンタ（正規化されたクロック）を導入すれば論理的には進行を一意に特定できる。しかし、そのような座標系では「どの時点で変数 $n$ が部屋の人数引く 1 に等しいか」といったプログラムの不変条件や中間状態を定義することが絶望的に複雑になり、人間の知的把握の役には立たない。 - **変数値による状態同定の誤謬**: プログラマはしばしば「特定の変数の値」を頼りにプロセスの進行を特定しようとするが、変数の値の意味自体がプロセスの進行度合いに依存して定まるため、これを座標として用いることは循環論法に陥り不可能である。 - **Böhm–Jacopini の定理への評価**: Böhm と Jacopini による「任意の流れ図は goto なしで表現可能である」という論理的証明（1966）に言及しつつも、任意の流れ図を機械的に jump-less な構造へ変換する操作は推奨されないと指摘した。機械的に変換された流れ図は元の図より透過的（transparent）になるとは限らず、最初から構造化された思考でプログラムを構築することこそが本質的であると論じた。 - **先行する議論への謝意と位置づけ**: Peter Landin、Christopher Strachey からの影響、1959 年の事前 ALGOL 会議で Heinz Zemanek が goto 文を代入文と同格に扱うことに明示的な疑義を呈していたこと、Hoare による goto の非常用脱出（alarm exits）への制限提案、Wirth と Hoare による case 構文の動的構造反映の議論を公平に記録している。 ## 強み / 弱点・課題 ### 強み - プログラミング言語設計およびソフトウェア工学における最重要転換点となり、[[構造化プログラミング]]運動の決定的な口火を切った。 - 単なる禁止令ではなく、人間の認知的限界（静的把握への適応と時間推移把握の弱さ）と数学的帰納法への親和性を根拠に、認知工学的・論理的な基礎づけを与えた。 ### 弱点・課題 - エラー処理や大域脱出（break, return, 例外処理）の具体的な言語機構（abortion clauses）の体系化は未完成であり、以後のプログラミング言語論争（Knuth の "Structured Programming with go to Statements" など）へ課題を残した。 - 本書簡自体は簡潔な意見表明（Letters to the Editor）であり、大規模プログラムにおける実証データや定量的検証は含まれていない。