アカウント名:
パスワード:
実のところ、goto文の乱用が危険であること、それの使いどころがどこか正しく広まっている今、gotoに関するバグがあったとしても、goto文がクソなのではなく、コードを設計するプログラマ(あるいは教育者)がクソなのでしょう。
商用のプログラムで例外処理を手厚くやると、あちこち例外処理だらけになるが、それを共通化する手段に、例外処理専用の関数を作るか、goto文で例外処理の共通処理コードのどちらが適切かは、設計者がきちんとメリット・デメリットを理解しているなら、goto文を使った実装でも問題ないだろう。
あまり良い例ではないが、フローチャートとか何も考えずに書いて、それを素直に実装すると goto文だらけになる。設計が駄目なら、駄目なコードになるし、そうでなければ全うなコードになる。(※フローチャートについて例示の一つであり、それの議論を繰り広げたい訳ではない。今は、代替の図解手法がいくらでもある。)
「gotoは事故を招くから用心深く使いましょう」よりも「用心なしでは事故を招くような要素のある言語を、全てのプログラマが使わざるをえないような状況はおかしい」と考えたほうがいい気がするなあ。
プログラミングの達人と、人間工学＆ユーザビリティの達人って、求められる思考が対極にあると思う。
そっち側の人は、新しい言語を作るんじゃないでしょうか。それに言語仕様に対する論争はもう、みんな議論し尽くした感があります。
(C言語以外の話は議論が発散するので置いておきましょう)
今の時代、コンパイラの警告とかコードチェックツールも随分進化した点は見逃せないと思います。到達しないコードや未初期化の変数に対する警告など、(見る気があれば) タイプミスレベルならかなり高い確度で検出されるようになっています。(商用で超遅かったりしますが)意味チェックに近い領域までやってくれるものもありますしね。
それでも誤りを犯すことに対して、人間工学＆ユーザビリティだとか議論するなら、具体的なコード例などの情報がないと、ツールで検出できるものか、言語の問題(仕様あるいはエラーとして扱うべきものをエラーとしていない)か、開発プロセスの問題かを切り分けできないでしょう。
言語仕様の改善は難しく、改善のトレンドは構文チェックツールだと思います。既存のプログラム言語は、過去の資産が多すぎて一律に文法を変えるとかは無理でしょう。それゆえ、警告を出すというのは妥当な妥協点でしょう。もし、構文を変えるなら、オプション指定で部分的に変更することになると思います。この場合、コンパイラのオプション指定も複雑になります。用心なしでコードを書くプログラマが細やかなオプション指定は難しいのではないでしょうか？
……というわけで、昨今のC言語のコーディングの問題について、人間の行動から導き出す妥当な解決手段は、大半は開発プロセス側(構文チェックをするとか)にあるんじゃないかなと思うのです。
そういう救済措置を作ってしまうと、デスマーチな現場では結局「コンパイルが通れば万事いいんだよ」ですので、構文チェックをスキップしたり、ワーニング抑制を入れて出荷するのが主流になるだけじゃないかなぁ。
最初から、仕様的に逃げ道が潰してある言語を渡したほうが、セキュアで利口だと思う。自由度の高い言語は、研究・実験用途にはいいんですけど…
use strict;use warnings;
「私はふざけるのは嫌いですよ（わざとやるとき以外は）」
別のツリーにもありますけど、『goto』を『包丁』におきかえると論法の過剰さがわかるのではないでしょうか。
家庭の包丁に安全装置はいらないけど、一日数十万食を作る食品工場の機械には必要だよ。正しく使えていれば問題ないと言うけど、プロだろうと一日に何千行も書いていれば、終わりごろには頭が朦朧としてくるわけで、普段絶対にやらないミスは、そういうときに起きるような。
製造業の工場の世界では、設計レベルで人災予防を組み込むのが当たり前なのだけど、ソフトウェアの世界じゃ、未だに「ああいうのは間抜けがやるミスだ」止まりのような。
グローバル変数でバグを作る奴もそいつの問題だからローカル変数もいらないよね。オブジェクト指向などもいらないよね。
大丈夫。それに関しては安心していい。
グローバル変数でバグを作る奴は、それをふさぐ方法を用意しても、そいつのコードの質が高まったわけではないから、別のバグをちゃんと作りこんでくれる。
オブジェクト指向でも、カプセル化や再利用性ができないコードをちゃんと作ってくれる。
なんて見当違いな極論…
元コメみたいな人が構造化プログラミングの意義を否定して相変わらず何でもgotoで済ませるからダイクストラが苦言を呈した、という計算機科学史を皮肉的に再現してるんでしょうか。
人間の脳は非同期事象とか状態遷移を扱うのが非常にヘタなのに一次元の実行順で解決しようとするから問題が起きるのであって、設計とは関係ないよ。
設計とかコーディングとか、そういう話にいけてうらやましい。
・「わたしがかいたから大丈夫」 「こんどは大丈夫、私がみたから」（作業的には、眺めただけ） 根拠のない自身・「だいたいうごく」「（80%も、)うごけばいいんだよ」「うごかないけど大丈夫です。」 問題意識の違い・「コンパイラーのバグである」、（確認もせずに）「相手が間違ってる」 自分のせいではない。 ※大抵は自分である。
これら３つを持ち合わせた人がいるんだ、どうしたらいいのか・・・
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
正しいコーディングスタイルが広まった今、罪なのは設計であってgoto文せいではない (スコア:1)
実のところ、goto文の乱用が危険であること、それの使いどころがどこか正しく広まっている今、
gotoに関するバグがあったとしても、goto文がクソなのではなく、コードを設計するプログラマ(あるいは教育者)がクソなのでしょう。
商用のプログラムで例外処理を手厚くやると、あちこち例外処理だらけになるが、
それを共通化する手段に、例外処理専用の関数を作るか、goto文で例外処理の共通処理コードの
どちらが適切かは、設計者がきちんとメリット・デメリットを理解しているなら、goto文を使った実装でも問題ないだろう。
あまり良い例ではないが、フローチャートとか何も考えずに書いて、それを素直に実装すると goto文だらけになる。
設計が駄目なら、駄目なコードになるし、そうでなければ全うなコードになる。
(※フローチャートについて例示の一つであり、それの議論を繰り広げたい訳ではない。今は、代替の図解手法がいくらでもある。)
Re: (スコア:0)
「gotoは事故を招くから用心深く使いましょう」よりも
「用心なしでは事故を招くような要素のある言語を、全てのプログラマが使わざるをえないような状況はおかしい」と考えたほうがいい気がするなあ。
プログラミングの達人と、人間工学＆ユーザビリティの達人って、求められる思考が対極にあると思う。
Re:正しいコーディングスタイルが広まった今、罪なのは設計であってgoto文せいではない (スコア:1)
そっち側の人は、新しい言語を作るんじゃないでしょうか。
それに言語仕様に対する論争はもう、みんな議論し尽くした感があります。
(C言語以外の話は議論が発散するので置いておきましょう)
今の時代、コンパイラの警告とかコードチェックツールも随分進化した点は見逃せないと思います。
到達しないコードや未初期化の変数に対する警告など、
(見る気があれば) タイプミスレベルならかなり高い確度で検出されるようになっています。
(商用で超遅かったりしますが)意味チェックに近い領域までやってくれるものもありますしね。
それでも誤りを犯すことに対して、人間工学＆ユーザビリティだとか議論するなら、
具体的なコード例などの情報がないと、ツールで検出できるものか、
言語の問題(仕様あるいはエラーとして扱うべきものをエラーとしていない)か、
開発プロセスの問題かを切り分けできないでしょう。
言語仕様の改善は難しく、改善のトレンドは構文チェックツールだと思います。
既存のプログラム言語は、過去の資産が多すぎて一律に文法を変えるとかは無理でしょう。
それゆえ、警告を出すというのは妥当な妥協点でしょう。もし、構文を変えるなら、オプション指定で
部分的に変更することになると思います。この場合、コンパイラのオプション指定も複雑になります。
用心なしでコードを書くプログラマが細やかなオプション指定は難しいのではないでしょうか？
……というわけで、昨今のC言語のコーディングの問題について、
人間の行動から導き出す妥当な解決手段は、大半は開発プロセス側(構文チェックをするとか)にあるんじゃないかなと思うのです。
Re: (スコア:0)
そういう救済措置を作ってしまうと、デスマーチな現場では結局「コンパイルが通れば万事いいんだよ」ですので、
構文チェックをスキップしたり、ワーニング抑制を入れて出荷するのが主流になるだけじゃないかなぁ。
最初から、仕様的に逃げ道が潰してある言語を渡したほうが、セキュアで利口だと思う。
自由度の高い言語は、研究・実験用途にはいいんですけど…
Re: (スコア:0)
use strict;
use warnings;
「私はふざけるのは嫌いですよ（わざとやるとき以外は）」
Re: (スコア:0)
別のツリーにもありますけど、『goto』を『包丁』におきかえると論法の過剰さがわかるのではないでしょうか。
Re: (スコア:0)
家庭の包丁に安全装置はいらないけど、一日数十万食を作る食品工場の機械には必要だよ。
正しく使えていれば問題ないと言うけど、プロだろうと一日に何千行も書いていれば、終わりごろには頭が朦朧としてくるわけで、普段絶対にやらないミスは、そういうときに起きるような。
製造業の工場の世界では、設計レベルで人災予防を組み込むのが当たり前なのだけど、
ソフトウェアの世界じゃ、未だに「ああいうのは間抜けがやるミスだ」止まりのような。
Re: (スコア:0)
グローバル変数でバグを作る奴もそいつの問題だからローカル変数もいらないよね。
オブジェクト指向などもいらないよね。
Re: (スコア:0)
大丈夫。それに関しては安心していい。
グローバル変数でバグを作る奴は、それをふさぐ方法を用意しても、
そいつのコードの質が高まったわけではないから、別のバグをちゃんと作りこんでくれる。
オブジェクト指向でも、カプセル化や再利用性ができないコードをちゃんと作ってくれる。
Re: (スコア:0)
なんて見当違いな極論…
Re: (スコア:0)
元コメみたいな人が構造化プログラミングの意義を否定して
相変わらず何でもgotoで済ませるからダイクストラが苦言を呈した、
という計算機科学史を皮肉的に再現してるんでしょうか。
Re: (スコア:0)
人間の脳は非同期事象とか状態遷移を扱うのが非常にヘタなのに一次元の実行順で解決しようとするから問題が起きるのであって、設計とは関係ないよ。
Re: (スコア:0)
設計とかコーディングとか、そういう話にいけてうらやましい。
・「わたしがかいたから大丈夫」 「こんどは大丈夫、私がみたから」（作業的には、眺めただけ） 根拠のない自身
・「だいたいうごく」「（80%も、)うごけばいいんだよ」「うごかないけど大丈夫です。」 問題意識の違い
・「コンパイラーのバグである」、（確認もせずに）「相手が間違ってる」 自分のせいではない。 ※大抵は自分である。
これら３つを持ち合わせた人がいるんだ、どうしたらいいのか・・・