**goto**とはプログラミング言語の構文のひとつであり、その使用を巡って論争が絶えないことで有名である。

## 概要
通常、`goto`は**無条件ジャンプ**を行うための構文であり、その名の通り「あそこの(あのラベルの)処理に飛べ！」という単純明解な機能である。
Cの`goto`を基準にするが、同一関数内である限り、ラベルが書ければ**どこにでも**ジャンプすることが出来、ジャンプ先から処理を継続する。

サポートする言語にはFORTRAN, BASIC, [C](https://dic.nicovideo.jp/a/c%E8%A8%80%E8%AA%9E) (当然C++も)と、メジャーな古参高級言語が名を連ねており、いかにも「由緒正しきスタンダードな機能です」感が漂うが、`goto`は決して濫用してはならないとされる。

### なぜ批判されるか
関数呼び出しはアセンブリでは`call`命令に対応するものであり、`ret`命令で`call`命令の場所に戻ってくることを前提としたものであるが、`goto`は無条件ジャンプ`jmp`命令に対応する。
すなわち関数呼び出しと違って原則として呼び出した場所に戻ってこないので、プログラムの構造をぶっちぎって構造化プログラミングを台無しにすることが出来てしまうのである。
ある意味構造化プログラミングの天敵ともいえる。

状況によっては特定の処理を飛ばす事も容易に行えてしまう。
たとえば、「ファイルを開き、データを読み込み、ファイルを閉じる」という処理があった時、「データを読み込む」処理に`goto`が入っていて、`goto`で飛んだ先から「ファイルを閉じる」処理に戻ってくるように書くのを忘れてしまうと、ファイルが開いたままになってしまうのである。

また、安易な`goto`の濫用は絡まり合うような処理の流れを生み、本人ですら処理の流れを把握することが困難なソースコードを作り出す。
絡まり合っていることから**スパゲティ・コード**と呼ばれる。

### 現実にはどうなのか
上記の批判などでも言われているように、`goto`文をみだりに使用すべきでないという点では議論はない。
一方で、`goto`文を用いずに高い可読性を実現出来ない場合には`goto`文を使用すべきとしているプロジェクトも存在する。

当然適した場所に限る、という前提であるが、`goto`を利用しているプロジェクトは非常に多い。
具体的には[Linuxカーネル](https://www.kernel.org/doc/html/latest/process/coding-style.html#centralized-exiting-of-functions)を挙げることが出来、例えば関数内のエラー処理の集約のために`goto`が頻繁に利用されている(例えば[RSA暗号の実装](https://github.com/torvalds/linux/blob/v4.19/crypto/rsa.c#L86)など)。
それ以外にもスクリプト言語の処理系は(大抵セルフホスティングしないので)主にCで記述されることが多く、中でも主要なPython (CPython), PHP, Ruby (YARV)などは、`goto`を用いた記述の適するパーサや有限オートマトンなどを実装していることが多いからという点も影響していると思われるが、いずれも`goto`による終了処理の集約が頻出している。
また[vimやEmacs](https://dic.nicovideo.jp/a/%E3%82%A8%E3%83%87%E3%82%A3%E3%82%BF%E6%88%A6%E4%BA%89)のソースにも`goto`を利用する記述があり、Cによるオープンソースのプロジェクトで`goto`を排除していると言えるものは多くないと言えるだろう。

勿論`goto`が適すると思われるような例であっても`goto`を利用しないという場合もあり、[GNU Scientific Library](https://www.gnu.org/software/gsl/)に於ける[常微分方程式ソルバのコード](http://git.savannah.gnu.org/cgit/gsl.git/tree/ode-initval2/rk4imp.c?h=release-2-5#n64)などはその例である(GNU Scientific Library全体として利用していないわけではなく、一部で`goto`を用いない書き方がされている)。

上記の例で`goto`を使用しない場合、同じ「後始末」のコードが反復して複数回出現している一方で、`goto`を利用する場合は関数ブロック末尾にのみ「後始末」のコードの記述を行い、適切なラベル位置にジャンプ、すなわち`goto`することで可読性とメンテナンス性が確保されているように見える。

実際このエラー処理フロー(を更に拡張したもの)を言語レベルでサポートしたものが例外(Exception)であるということも出来る。
つまり例外は後述の機能制限版の`goto`の一種であるということも出来るのである。
なお、例外は無条件でのジャンプこそ出来ないものの、同一関数内という制限を受けずスタックを遡上して関数外に出ること(大域脱出)が可能であるため、その点で`goto`**より強力な機能**である。

このように、比較的新しい言語では`goto`の機能を制限して別の構文として実装されることが多く、そのような言語では無条件ジャンプとしての`goto`が必要になるケースは少ない(少なくともこの項を書いている人は遭遇したことはない)。
逆に言えばそのような言語機能を持たない言語やパフォーマンスを重視する言語(C++など)では`goto`を使った方が可読性やパフォーマンスが向上するケースもまま見られるのである。

## 論争
`goto`は論争を引き起こしがちな構文である。
これは無条件ジャンプとしての`goto`が構文として自由かつ強力過ぎることに起因するということに関しては恐らく議論はない。

`goto`に関してよく行われる論争としては、大きく分けて2つに分類することが出来るだろう。

### `goto`のある言語で使うべきか否か
要するに`goto`構文は自由過ぎる上に強力過ぎ、簡単に濫用出来てしまうからそもそも使わない方がいいのではないか、という議論である。
グラフ理論の最短経路探索アルゴリズムで有名なダイクストラらの1968年の論文「Go To Statement Considered Harmful (Go To構文は有害だと考えられる)」を根拠として主張されることが多い(なお**Cの誕生が1972年**であり、それより早い)。

`goto`を用いた処理は反復や条件分岐などの基本的な構文を使って書き換えることが出来る(構造化定理)から`goto`は不要である、という主張は、そもそも書き換えによって可読性や性能がどうなるかについて言及されておらず、実際にそれらを損なうことがあるため`goto`を利用すべきでない積極的な理由にはならない。
しかし`goto`構文のその自由度と強力さ故に、なるべく利用せずに書くべきであり、またプログラミングに十分習熟しない間は(`goto`に頼ってしまわないためにも)使用すべきでない、などの主張は、実際のプロジェクトに於いても`goto`の使用を回避する根拠となっている。

結局のところ利用すべきか否か、というのは、プロジェクト参加者やそのプロジェクトの運営体制(コーディング規約が適切に定められているか、テストは記述されているか、コードレビューは行われているか)などにも依存するものであり、強力過ぎるから止める、便利だから使う、という観点だけからは判断することは出来ないと言える。

### プログラミング言語は`goto`構文を持つべきか否か
上記で述べた通り、無条件ジャンプとしての`goto`構文が自由過ぎる上に強力過ぎるというのは広く合意されていると思われる。
そのため、近年のプログラミング言語の傾向としては(優秀なプログラマーからそうでない者まで)大人数で安全な開発を行えるようにすることを重視するという考えもあり、無条件ジャンプとしての`goto`が採用されることはまずなくなっている。

[Go][]やDは`goto`構文を採用しているが、表記こそ`goto`であるものの、後述のように用途制限により"[機能制限版の`goto`](#substitution)"となっている。

## 新しい言語における`goto` ## {#substitution}
構造化定理により、`goto`を用いた処理を反復・分岐などの組み合わせに書き換えることは理論上可能であるが、上記で示した通りその書き換えを行うことで性能や可読性について不利になるケースもある。

この点に対して、比較的新しいプログラミング言語の多くは無条件ジャンプとしての`goto`ではなく、より限定された範囲でのジャンプ制御命令(`break`, `continue`, `throw`, etc.)を代替として提供していることが多い。

これらの命令はジャンプ制御を行うという点においては基本的に`goto`と同義である。
その代わり、ジャンプできる先を制限し、最終的に本来の処理の流れに戻ってくることを保証するなどにより、複雑なプログラムフローとならないように言語レベルでの制限（あるいは構造化プログラミングの補助）を行っている。

### 制限の強まった`goto`
先述のように、新しい言語でも`goto`を採用している言語はある。
これらの言語の`goto`は比較的Cに近い機能を有しているが、使用するための制約を強くしたり無条件で処理をスキップしないようにするなど、Cよりも自由度や機能を制限したものとなっている。

#### D
Dの`goto`はCと同様に同じ関数の内部のラベルしか参照出来ないようになっている。
それに加えて`goto`によって変数の初期化をスキップするようなジャンプは禁止され、またジャンプする場合であっても`finally`節の実行は回避されないようになっている。

#### Go
[Go][]でも`goto`構文は採用されており、やはりCと同様に同じ関数の内部のラベルしか参照出来ない。
加えて`goto`する時点でスコープに入っていない変数がジャンプ先ではスコープに入っているような(*i.e.* 初期化をスキップする)ジャンプは禁止され、またより内側のブロックへのジャンプも出来ない仕様となっている。

## GOTO 関連動画
<iframe src="http://ext.nicovideo.jp/thumb/sm486838" class="nicovideo" scrolling="no" width="312" height="176" frameborder="0"></iframe>

## GOTO 関連項目

* プログラミング関連用語の一覧
* 構造化プログラミング
* 鉄砲玉
* リンク / URL / ジャンプ
* 5103

[Go]: https://dic.nicovideo.jp/a/go