＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
なぜ「ＧＯＴＯ文」を使っては、いけないのですか？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-04-28 15:06
あ、りばぁさんの投稿に気付いてなかった．．ごめんなさい。 
しかも、「熱血VBプログラマ応援団」の最新記事が出ているとは、 サイクル早いな！しかも、内容がホットな話題！ 
＞Exitステートメントは、自分が脱出する対象を明示して記述するから という考えは無かったですね．．． (1)Do～Loop、Exit Do (2)For～Next、Exit For (3)Sub～End Sub、Exit Sub がそれぞれ１セットと頭にあったので Exitを一括りに考えると言うのはありませんでした。 物の見方を変えると、色んな発見がありますね。 | ||||||||
|
投稿日時: 2004-04-29 11:10
なんか、無理矢理って気がしないでもない。この事例で発生させている問題は、VB.NETから書き換えているから発生するのであって、最初からCなりC#なりで組んでいたら発生しない問題ですよね。また、このケースもWhileとSwitchの組み合わせだからできるのであって、WhileとWhileの組み合わせならできません。なんか、うまく話をすり替えているような気がする。 私は別に「ループフラグ」を持たせて、多重ループからの脱出をやっていますけど、gotoとどちらが「見やすいか」ということで話題にはなります。 | ||||||||
|
投稿日時: 2004-04-30 11:29
# 脱線ですが一言
ですよね。それに、「VBがC#やJavaよりもさえている1つの事例」というタイトルでありながら、 C#に対する事例しかないのも残念です。次を期待します。 # Javaのラベルつきbreak文の方が Exit XXX より柔軟ですからね...。 # まあ、Javaより優れている点は、もっと見た目に分かり易いのがあるから説明不要かもしれませんが。 | ||||||||
|
投稿日時: 2004-04-30 11:38
ひえ～っ 「飼いならされた goto 文」 に着目したのですが…ネタを誤ったかしら。
| ||||||||
|
投稿日時: 2004-04-30 14:08
「飼いならされた goto 文」はうまいと思いましたよ。 あと、同時にはにまるさんの「＠ＩＴさんへ質問：会議室って偶に記事のネタになっています？」は真実だったのかななんておもったり 
| ||||||||
|
投稿日時: 2004-05-04 15:15
「飼い慣らされたgoto文」というのは、「なるほど～！」と思いました。著者の川俣さんは、２年ほど前まではちょくちょく会議室の方でもお名前を見かけているのですが、最近はROMされているのでしょうかねぇ？？？他にも、こちらの記事も、会議室が元ネタになっているようです。 | ||||||||
|
投稿日時: 2004-05-07 18:36
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
◆ ＧＯＴＯ文自体のマトメだよ～ん ◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆ また、また個人的主観でまとめです。 個人的主観なので以下に御注意下さい。 ・言葉じりとか勝手に変えています。 ・原本で「思う」と記述されていても断言文にしています。 ・原文が解らない可能性があります。 ・はにまる語に変えた結果、同じ内容の物は割愛しました。 ・複数の投稿を１つにまとめたりもしています ・「業務系のみ経験された方」と「制御系（Ｃ言語）も経験のある方」では 頭にあるフローパターンの数が異なります、はにまるは「業務系のみ」なので御注意を！ ---------------------------------------------------------- ［ＧＯＴＯ文が駄目な理由／問題点］ ・ソース自体の流れをＧＯＴＯ文で上下へ交差する様な記述をする人がいた、 その結果、フローを追いかけ難くなり、読む気が失せ、メンテンナンス性に欠ける問題が発生し その要因として駄目となった。 ・入口・出口は極力一つにする概念に反する可能性がある為。 ・「GOTO文を使ってはいけない」というのが、公然と広まったのはBasicが広まったころと思う 古いBasicの場合、GOTO文では行番号を付けてコーディングしないといけなかった為、 行番号を再番すると障害の温床となった、それが、問題のルーツ。 ・ただのGOTOだと無節操に使うと、書き手の支配下から逸脱した動作を 簡単に起こし易くなる為。 ・ＧＯＴＯ文の問題は、「分岐／戻る／繰返す／処理を呼ぶ／処理中断」と表現の多用性にあり どの表現を示しているのか読み手が即座に判断出来ない為。 ・低級命令（マシン語に近い）をアプリに入れると一般的には読み難くなる為。 ［ＧＯＴＯ文が良い理由］ ・サイズとか処理速度の恩恵がある（言語仕様に影響する？） ・人の思考に近い記述を網羅出来ていない言語では それをサポートする為にＧＯＴＯ文が必要、つまり使い回しが柔軟。 ［ＧＯＴＯ文を使う時］ ・下記の命令文が揃っていない言語では、その代用として有効。 １．指定回数まで繰返制御する For文 ２．指定条件まで繰返制御する Do..Loop文(While/Until) ３．繰返制御を抜ける Break文 ４．繰返制御の開始位置に戻る Continue文 ５．特定処理を呼出て戻す Call文 ・パターン化された構成内部で利用する場合 ・FORTRAN Ⅳという言語では、IFの中に書ける文は１つだけでELSEは無く ループ処理はDO～CONTINUEだけ、この様な言語仕様では利用する他無い。 ・割り込みや全くプロセスを切り替えなければならない場合。 ・プログラムが続行不可能な状態では、異常終了させる為にGOTOを使う。 ・ＶＢのOn Error Gotoはエラーハンドリングの手段として記述する為、 問題は無いが、飛び先ラベル名は決めておけ。 ・重複した入れ子構造から抜ける時。 ・マシン語レベルの言語 ・Driver などでは異常から抜ける時。 ・gotoを使用しないようにすると、かえって構文が複雑になる場合も多い その時は、意地を張らずにgotoを使え ［ＧＯＴＯ文のデメリットを緩和させる手段］ ・後日保守する人へ、コメントで謝っとけ ・開発時はそのプログラムにどっぷりだから理解できてしまうが、後日まで覚えてい訳では無い、 原則禁止で、皆が冷静な段階で取り決めた限定されたケースのみＯＫとさせる。 ・ＧＯＴＯ文の飛び先であるラベル名に飛ぶ意味／理由を記述する。 ［その他］ ・「ＧＯＴＯ文を使うな」は、過去の遺産になりつつある言語記述制約。 ・IF文は考えようによると「条件付きジャンプ」 ・GOTO文を使わなくていいように整理されているのが今の開発言語 For や Do/Loop などは、制御構造のためのデザインパターンとかフレームワークに相当する。 それらを使わずにGOTO文を使うのは、パターンやフレームワークの存在を無視する事に相当する。 ・「○○を使用しては、いけない」となると大抵は例外があり結果、使用しても良い状態に陥る。 「○○を”安易に”使用しては、いけない」とすれば、利用時の考慮点が提示出来て、 意図した方向誘導出来る。 ・本物のプログラマはGOTOを使うことを恐れない ・例外を除いた通常処理でGOTO文使わないといけない状況になったら、 「リファクタリングしろ。」のサイン。不吉な匂い ・プログラムの途中で抜け出るコーディングは嫌、プログラムの最後に飛ばせ。 ・ループからのbreakは嫌。 ・根っこは「より分かりやすく読みやすくメンテナンスしやすい」コード への要求なので。 最終的に「GOTOの方が理解しやすい」ソースになるのであれば使ってよい ・「GOTOは有害だ」と言ったのも「BASICなんかやってると脳に回復不可能な ダメージを受けてしまう」と言ったのもDijkstra先生で、 それらは「構造化プログラミングしましょう」という主張の一環。 ・林晴比古氏が著書「BASICによるプログラミングスタイルブック」 （およびその姉妹編「Cによるプログラミングスタイルブック」)で書かれていた事。 1.GOTO文を使うことを覚えよ 2.GOTO文を使わないことを覚えよ 3.時々GOTO文を使うことを覚えよ 分岐構文というものを知らなければ、そもそもプログラムを組むことはできない。 だからまずGOTO文を使うことを覚えよ。 GOTO文の機能を知ったうえで、下手にGOTO文を使えばプログラムの流れが追いにくくなり 収拾がつかなくなることから、構造化プログラミングの理論とそのための構文が発明され、 GOTO文の機能はそれらの構文によって隠蔽されるようになった、ということを理解すべきである。 この段階では裸のGOTO文を使わないプログラムを覚えなければならない。 GOTO文を使わないプログラムを書けるようになった上で、それでもGOTO文を使ったほうが 分かりやすいプログラムが書ける場合もある、ということが分かるようになれば一人前である。 ・ＧＯＴＯ文は、関数／メソッドを飛び越える事は出来ないので昔程、問題では無い。 ・言語設計者にとって、GOTO 的な挙動はプログラミングに必要だという認識はあるが 「どこへでも飛ばせてしまう」事を防ぐ為、Break/Continue/try catch/On Error等の 「制限付き GOTO 文」を実装させている。 ・下記の条件を満たせる場合、使ってよい １．処理の実行手順が整理されている ２．プログラムの流れがドキュメントに整理されて記述されている ３．ドキュメントとソースが一致している ４．ソース上の箇所を容易にドキュメント上で探すことができる または、質問がある都度、すぐにドキュメントを示すことができる ５．この２つをいつまでも（システムが代替わりするまで）自分で保守できる ［参考］ ・「オブジェクト指向技術に関する一考察 」 ・「第3回 VBがC#やJavaよりもさえている1つの事例」 ［その他 of その他］ ・今日のトリビア：結局、全てIF文とGOTO文で書ける。 ・GOTOと後藤さんの違いに注意！
・使ってよろしいです！ by CHNさん
や、、、やっと終わった．．． | ||||||||
|
投稿日時: 2004-11-27 10:31
結論が出た後で悪いが、あまりに昔からある懐かしい議論じゃて、少し思い出話がしたくてのぅ。
わしがプログラムがはじめたころはのう、FORTRANをつかっておったんじゃ。 このころのFORTRANは IF THEN ELSE END なんて構文はなくてのう、 IF 評価式 実行文とか IF 評価式 (文番号1、文番号2、文番号3）なんてものしか なかったんじゃ。今の若いもんにゃ想像もつかねぇだろうな。 じゃから IF (A>0) GOTO 100 なんとか GOTO 200 100 CONTINUE かんとか 200 CONTINUE とかいうコーディングしかできんかった。 そのうち、えー大工さんとか言ったかのう、順次・反復・分岐だけでプログラムができるいいだしてのう、そのうちIF THEN ELSE ENDという構造ができて喜んじゃものじゃ。 さて、お茶でも。。。ずるずる。 どこまで話したかな。 ああそうじゃ、GOTOをつかっちゃねんねぇといったのはやっぱり大工さんだっかのぅ。 でもじゃ、CのBreakみたいなものはなかったで、DO文から複数の場所で抜け出したり、 例外の処理を作るのにやはり使わなきゃならんかったのぅ。 そうそう、IF THEN ENDができてからもIF THEN ENDの外からTHENとENDの中へGOTOする やつもおったのう。 はっはっは。ただの昔話じゃ、気にせんでおくれ。 [ メッセージ編集済み 編集者: ほろりん 編集日時 2004-11-27 10:40 ] | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.