GOTOとはプログラミング言語に今も残る因習の一つである。古の昔、この機能の是非をめぐって大論争が起きた事で悪名高い。
歴史上幾度となく総括されかかったが未だにしぶとく生き延びている。単純な生物は強い。
概要:
その名の通り「あそこの処理に飛べ!」という単純明解な機能である。ラベルが書ければどこでも飛べる上にデフォルトでは戻ってこないため、関数呼び出しと違ってプログラムの構造をぶっちぎれる。当然スパゲティも絡まり放題なので昔から忌み嫌われてきた。
FORTRAN, BASIC, C(当然C++も)と、サポートする言語を挙げるだけでも「権威あります」感が漂うが、基本的にGOTOに頼る設計はダサいとされている。今時の言語はまず採用しない、といいたい所なのだが、D言語のように「まさかの時のGOTOステートメント!」などといいだすひねくれ者もいるから侮れない。
まあ実際GOTO賛成派の言い分も一理あり、高級な文法で大げさな事を書くより「こんなのGOTOで一発だろ」という場面があるのは事実。最後に物を言うのが職人の指先なのはどこの世界も一緒である。思想的に正しくなかろうと動くものを作らなければ始まらない。
くれぐれも自分の足を撃たないように注意して使うべし。
構造化プログラミングとgoto
構造化プログラミングの構成要素(順次、反復、分岐)から考えるとgotoは不要であり、gotoを使って書かれる処理は構造化プログラミングの構成要素に書き換えて実現することができる。しかし、その書き換えを行った方が(実行速度、可読性、実行時記憶域について)不利になるケースが希にある。
いくつかのプログラム言語は、gotoより限定された範囲でのジャンプ制御命令(break, continue, exception...など)を用意することでこれを解決している。これらの処理は基本的にgotoと同義である。その代わり、ジャンプできる先を制限することにより、複雑なプログラムフローとならないように言語レベルでの制限(あるいは構造化プログラミングの補助)を行っている。手続き型プログラム言語のほとんどは、このような制限されたgoto(ジャンプ制御)をサポートしているため、gotoに頼る設計が優れていないとかひねくれているとかいうわけではない。言語には言語なりの考え方がある。
gotoを用いなければ、処理の流れの追いづらいスパゲティプログラムができあがる可能性は低くなるが、だからといってそれだけでプログラムの可読性が向上するわけではない。gotoを用いても、可読性や構造を損なわずにプログラムを記述することはできる。gotoを因習としてそれがアンチパターンだと単純に考え思考停止するのはいいことではないし、面倒だからgotoを用いて処理の流れを強引に制御するのもいいことではない。
gotoに賛成/反対とか、思想的に正しいとか間違っているとか、gotoを使うのが職人芸であるとか、そのような話ではなく、それをどのように用いるのが適切であるのか、それを用いる必要があるのか、言語が別の適切なジャンプ命令を持っていないか、もしくは記述するアルゴリズム・実装方法により適切な形・流れはないのか、gotoを使ってプログラムを行う場合はどのように利用すればスマートな記述ができるのか、それらを考え続ける事が重要である。(ご利用の際にはコメントなどでそのgotoが何を意味するのか併記するのも大切です)
GOTO 関連動画
GOTO 関連項目
http://dic.nicomoba.jp/k/a/goto


ページ番号: 4630852
リビジョン番号: 1247819
読み:ゴトー
初版作成日: 11/05/11 23:47 ◆ 最終更新日: 11/08/04 02:23
編集内容についての説明/コメント: 構造化プログラミングについて追記しました
記事編集 / 編集履歴を閲覧 / Twitterで紹介





JASRAC許諾番号: 9011622001Y31015
ヘッダー:固定
ヘッダー:追従