アカウント名:
パスワード:
実のところ、goto文の乱用が危険であること、それの使いどころがどこか正しく広まっている今、gotoに関するバグがあったとしても、goto文がクソなのではなく、コードを設計するプログラマ(あるいは教育者)がクソなのでしょう。
商用のプログラムで例外処理を手厚くやると、あちこち例外処理だらけになるが、それを共通化する手段に、例外処理専用の関数を作るか、goto文で例外処理の共通処理コードのどちらが適切かは、設計者がきちんとメリット・デメリットを理解しているなら、goto文を使った実装でも問題ないだろう。
あまり良い例ではないが、フローチャートとか何も考えずに書いて、それを素直に実装すると goto文だらけになる。設計が駄目なら、駄目なコードになるし、そうでなければ全うなコードになる。(※フローチャートについて例示の一つであり、それの議論を繰り広げたい訳ではない。今は、代替の図解手法がいくらでもある。)
「gotoは事故を招くから用心深く使いましょう」よりも「用心なしでは事故を招くような要素のある言語を、全てのプログラマが使わざるをえないような状況はおかしい」と考えたほうがいい気がするなあ。
プログラミングの達人と、人間工学＆ユーザビリティの達人って、求められる思考が対極にあると思う。
別のツリーにもありますけど、『goto』を『包丁』におきかえると論法の過剰さがわかるのではないでしょうか。
家庭の包丁に安全装置はいらないけど、一日数十万食を作る食品工場の機械には必要だよ。正しく使えていれば問題ないと言うけど、プロだろうと一日に何千行も書いていれば、終わりごろには頭が朦朧としてくるわけで、普段絶対にやらないミスは、そういうときに起きるような。
製造業の工場の世界では、設計レベルで人災予防を組み込むのが当たり前なのだけど、ソフトウェアの世界じゃ、未だに「ああいうのは間抜けがやるミスだ」止まりのような。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
正しいコーディングスタイルが広まった今、罪なのは設計であってgoto文せいではない (スコア:1)
実のところ、goto文の乱用が危険であること、それの使いどころがどこか正しく広まっている今、
gotoに関するバグがあったとしても、goto文がクソなのではなく、コードを設計するプログラマ(あるいは教育者)がクソなのでしょう。
商用のプログラムで例外処理を手厚くやると、あちこち例外処理だらけになるが、
それを共通化する手段に、例外処理専用の関数を作るか、goto文で例外処理の共通処理コードの
どちらが適切かは、設計者がきちんとメリット・デメリットを理解しているなら、goto文を使った実装でも問題ないだろう。
あまり良い例ではないが、フローチャートとか何も考えずに書いて、それを素直に実装すると goto文だらけになる。
設計が駄目なら、駄目なコードになるし、そうでなければ全うなコードになる。
(※フローチャートについて例示の一つであり、それの議論を繰り広げたい訳ではない。今は、代替の図解手法がいくらでもある。)
Re: (スコア:0)
「gotoは事故を招くから用心深く使いましょう」よりも
「用心なしでは事故を招くような要素のある言語を、全てのプログラマが使わざるをえないような状況はおかしい」と考えたほうがいい気がするなあ。
プログラミングの達人と、人間工学＆ユーザビリティの達人って、求められる思考が対極にあると思う。
Re:正しいコーディングスタイルが広まった今、罪なのは設計であってgoto文せいではない (スコア:0)
別のツリーにもありますけど、『goto』を『包丁』におきかえると論法の過剰さがわかるのではないでしょうか。
Re: (スコア:0)
家庭の包丁に安全装置はいらないけど、一日数十万食を作る食品工場の機械には必要だよ。
正しく使えていれば問題ないと言うけど、プロだろうと一日に何千行も書いていれば、終わりごろには頭が朦朧としてくるわけで、普段絶対にやらないミスは、そういうときに起きるような。
製造業の工場の世界では、設計レベルで人災予防を組み込むのが当たり前なのだけど、
ソフトウェアの世界じゃ、未だに「ああいうのは間抜けがやるミスだ」止まりのような。