プログラミング言語におけるgoto文（ゴートゥぶん、）とは、指定された行番号やラベルに無条件に計算の実行プロセスをジャンプ（移動）させるプログラムの命令を言う。goto文を多用すると、テキストとしてのプログラムの文章構造と計算の実行プロセスが乖離してしまいソフトウェア工学的手法が適用できなくなる（順序的プログラムではなくなる）ことから、その使用はできるだけ避けるべきであるとされる。Cなどの構造化プログラミング言語においては、goto文はむやみに使ってはいけないと言う暗黙の約束がある。これは、goto文が原始的で自由度の高すぎる機能であるため、安易なgoto文の使用はプログラムの構造化を妨げ、デバッグなどが行いにくくなり、バグの発生や、メンテナンス性・可読性の低下の原因になりやすいからである。しかし、多重にネストしたfor文やif文、while文などでエラー処理や例外処理などが複雑になる場合はgoto文を使った方がプログラムがすっきりと書けるケースもあるため、プログラムの構造を熟知したプログラマが状況に応じて使い分けるものとされている。オブジェクト指向言語の場合は、エラー処理や例外処理などの仕組みが充実しているためにgoto文が必要になるケースが少ない。そのため、言語仕様として始めから用意されていないケースもある。こうした言語としては、Javaなどが挙げられる。一方では、で、2009年にリリースされたバージョン5.3からgotoが追加されたように、高度化する言語構造の中でgoto文が一定の評価を受ける例もある。BASICの様な言語や低レベルの制御言語ではgoto文は不可欠であり、goto文を利用しないと分岐やループを使ったプログラムが記述出来ないものもある。しかし、拡張されたBASICの中には、goto文がほとんど不必要になってしまっているものもある。前述のように、goto文の安易な使用はプログラムの可読性を著しく低下させる。こうした可読性の低いコードのことを、制御構造が複雑に絡まっているという意味を込めて、スパゲティコードと呼ぶことがある。C言語の場合では、指定したラベル付き文にジャンプする。goto ラベルの例文として以下に記す。goto文が実行されると、clearラベルの付いた文にジャンプし、文codice_1を実行する。つまり、プログラムはclearラベルの付いた文に処理を移し、処理を続けるということである。ダイクストラの記事をきっかけとしてgoto文の是非について当時の計算機科学者の間で論争となった。構造化プログラミングを提唱するダイクストラは、理論の帰結から、goto文を使うべきでないとする。ダイクストラによる“Go To Statement Considered Harmful”の趣旨は次の通りである。その一方でクヌースの指摘によると、ダイクストラは“Structured Programming”においてはgoto文には触れていない。実際に“Structured Programming”においては“sequencing should be controlled by alternative, condtional and repetitive clauses and procedure calls, rather than by statements transferring control to labelled points.”との1文があるのみでそれ以外では触れていない。また、3つの基本構造についても、“Go To Statement Considered Harmful”においては“I do not claim that the clauses mentioned (引用者註: 順次・分岐・手続き呼び出し・反復) are exhaustive in the sense that they will satisfy all needs”とし、プロセスの進捗を表す簡潔な指標が存在する限りは3つの基本構造には固執していない。「構造化プログラミングの観点からgoto文を使うのは望ましくない」ものの「単にgoto文を使わなければ見通しが良くなる」という考えは“Go To Statement Considered Harmful”でも否定されており、goto文の有無のみに固執するのは不毛である。構造化プログラミングの本質の一つは、状態遷移の適切な表現方法とタイミングを見極めることである。一方、goto文を使わずに3つの基本構造による代替を行うと、理論上は同値であっても実際にはプログラムの実行速度や記憶容量の点で性能が劣化する場合があることを示し、goto文を擁護する意見もあった。ACMの年次大会(1972)の討論会では、トップダウンでプログラムを分割するよりgoto文を使う方が適した事例があり、証明には関心がないという意見(William Wait)や、goto文を残せば選択の余地があるが、無くしてしまうと必要になったとき困るだろうという意見(Guy Steel)などが出された。条件文とgoto文を正しく使うことで、FORTRANでもALGOLの基本機能を実現できることを例に挙げ、プログラマは必要な機能がプログラミング言語で直接表現できないとき、どのように実装するか工夫できるべきであるという主張もあった(S.W.スリア)。また、ドナルド・クヌースは、著書「文芸的プログラミング」の中で、再帰呼出しのある正当なプログラムを、正当な変形によってループによるプログラムに書き換えた結果、gotoを使ったものになる、といったような例をいくつかあげている。現在C言語を除く主流派の言語では、そのままのgoto文はほとんど見られなくなった。替わりにbreak文、continue文、もしくは例外処理のような特殊脱出(去勢されたgotoとも呼ばれる)をサポートし、単純な制御構造だけでは弱いと考えられる部分を補っている。さらにクロージャやコードブロック、継続のような強力な制御機構を使い、抽象度の低いgoto文を使う必要性を低くした言語もある。例えばHaskellにおいてはモナドを利用して例外や非決定性計算などの様々な制御構造を表現できる。またSmalltalkやIoにおいても制御構造はブロックを扱うメソッドとして表現している。Scheme等でサポートされている継続は「引数付きgoto」と呼ばれることもある。一方で、例えば1999年から設計されたD言語はgoto文を含んでいる。にも2009年にリリースされた5.3において制限された形ではあるがgoto文が追加された。それまでの職人芸的なプログラミングの時代から、構造化プログラミングというパラダイムの提唱によって、プログラミング技法の体系化を試みるプログラミング工学という学問が芽生えたと言っても過言では無いだろう。なお、論文“Go To Statement Considered Harmful”は、その半ば挑戦的な題名がプログラミング以外の様々な分野に及んで評判となり、それをもじった様々な “～ Considered Harmful”といった論説やジョークが生まれた 。極めつきは、何かが有害であることだけが強調される題名の有害性を指摘した“‘Considered Harmful’ Essays Considered Harmful”であろう。ダイクストラは What led to “Notes on Structured Programming” (『「構造化プログラミングに関する覚え書き」へと導いたもの』)で、“A case against goto statement” (『Goto 文が不利な場合』)と題した論文を投稿したが、出版を早めるために編集者により “letter to the Editor” (『編集者への手紙』)と改題され、その過程でその編集者独自の考案で新たなタイトル("The goto statement considered harmful")を付けられた。その編集者とはニクラウス・ヴィルトであった、と述べている。同じくWhat led to "Notes on Structured Programming" においてダイクストラは、Millsによって矮小化されたgoto文廃止という概念のもと、IBMが用語としての「構造化プログラミング」を盗用したと語っている。ダイクストラの著書は、分かりにくいことと誤解を招きやすいことで定評がある。それを憂いたは、ダイクストラ流のプログラミングについて体系化した書籍「プログラミングの科学」(The Science of Programming)を書いた。

出典:wikipedia