導入
古いCOBOLのコードを見ると、GO TO という命令に出会うことがあります。今では「使うべきではない」とされる命令ですが、なぜCOBOLの歴史にこれほど深く関わっているのでしょうか。
説明
GO TO は、指定した段落へ無条件にジャンプする命令です。
*> 古いスタイルの例（現代では非推奨）
MAIN-PROCESS.
DISPLAY "処理A".
IF WS-FLAG = "Y"
GO TO PROCESS-B
END-IF.
DISPLAY "処理C".
STOP RUN.
PROCESS-B.
DISPLAY "処理B".
GO TO MAIN-PROCESS.一見便利そうですが、GO TO を多用すると、処理の流れがあちこちに飛び回り、コードを読む人が「次にどこへ進むのか」を追いかけられなくなります。この状態は俗に スパゲッティコード と呼ばれます。
graph TD
A[処理A] -->|条件による分岐| B[処理B]
B -->|GO TOで戻る| A
A --> C[処理C]
B -.GO TOで別の場所へ.-> D[遠く離れた段落]
D -.さらにGO TOで.-> A
1968年、計算機科学者 エドガー・ダイクストラ が発表した論文「Go To Statement Considered Harmful（GO TO文は有害と考えられる）」は、まさにこの問題を指摘し、大きな議論を呼びました。この流れの中で提唱されたのが 構造化プログラミング という考え方です。
- プログラムは、順次（上から下へ）・選択（IF/EVALUATE）・繰り返し（PERFORM） の3つの基本構造の組み合わせだけで書ける（書くべきだ）、という原則。
- ジャンプ先が予測できる
GO TOに頼らず、呼び出したら必ず戻ってくるPERFORMを使えば、処理の流れが一本の筋道として追いやすくなる。
第5章でここまで学んできた PERFORM（基本・TIMES・UNTIL・VARYING）は、まさにこの構造化プログラミングの原則をCOBOLで実現するための道具でした。呼び出し元に必ず戻ってくるPERFORMは、GO TOのように処理の流れを追いにくくすることがありません。
現代のCOBOLプログラミングでは、GO TO はほぼ使われず、PERFORMによる構造化された書き方が標準です。ただし、古い資産のコードには今もGO TOが残っていることがあるため、保守エンジニアとして「読めること」は依然として大切です。
試すには
レッスン25〜28で書いたPERFORMのコードを振り返り、「呼び出したら必ず元の場所に戻ってくる」という性質が、コードの流れをどれだけ追いやすくしているか考えてみましょう。もし同じ処理をGO TOだけで書いたらどうなるか、想像してみるのもよい練習になります。