「C言語の開発者によるgoto文の使い方を対象とした実証研究の結果、「goto文は無害だと考えられる」」記事へのコメント

正しいコーディングスタイルが広まった今、罪なのは設計であってgoto文せいではない

[plauda (46850)]

実のところ、goto文の乱用が危険であること、それの使いどころがどこか正しく広まっている今、
gotoに関するバグがあったとしても、goto文がクソなのではなく、コードを設計するプログラマ(あるいは教育者)がクソなのでしょう。

商用のプログラムで例外処理を手厚くやると、あちこち例外処理だらけになるが、
それを共通化する手段に、例外処理専用の関数を作るか、goto文で例外処理の共通処理コードの
どちらが適切かは、設計者がきちんとメリット・デメリットを理解しているなら、goto文を使った実装でも問題ないだろう。

あまり良い例ではないが、フローチャートとか何も考えずに書いて、それを素直に実装すると goto文だらけになる。
設計が駄目なら、駄目なコードになるし、そうでなければ全うなコードになる。
(※フローチャートについて例示の一つであり、それの議論を繰り広げたい訳ではない。今は、代替の図解手法がいくらでもある。)

Re:

[Anonymous Coward]

「gotoは事故を招くから用心深く使いましょう」よりも
「用心なしでは事故を招くような要素のある言語を、全てのプログラマが使わざるをえないような状況はおかしい」と考えたほうがいい気がするなあ。

プログラミングの達人と、人間工学＆ユーザビリティの達人って、求められる思考が対極にあると思う。

Re:正しいコーディングスタイルが広まった今、罪なのは設計であってgoto文せいではない

[plauda (46850)]

そっち側の人は、新しい言語を作るんじゃないでしょうか。
それに言語仕様に対する論争はもう、みんな議論し尽くした感があります。

(C言語以外の話は議論が発散するので置いておきましょう)

今の時代、コンパイラの警告とかコードチェックツールも随分進化した点は見逃せないと思います。
到達しないコードや未初期化の変数に対する警告など、
(見る気があれば) タイプミスレベルならかなり高い確度で検出されるようになっています。
(商用で超遅かったりしますが)意味チェックに近い領域までやってくれるものもありますしね。

それでも誤りを犯すことに対して、人間工学＆ユーザビリティだとか議論するなら、
具体的なコード例などの情報がないと、ツールで検出できるものか、
言語の問題(仕様あるいはエラーとして扱うべきものをエラーとしていない)か、
開発プロセスの問題かを切り分けできないでしょう。

言語仕様の改善は難しく、改善のトレンドは構文チェックツールだと思います。
既存のプログラム言語は、過去の資産が多すぎて一律に文法を変えるとかは無理でしょう。
それゆえ、警告を出すというのは妥当な妥協点でしょう。もし、構文を変えるなら、オプション指定で
部分的に変更することになると思います。この場合、コンパイラのオプション指定も複雑になります。
用心なしでコードを書くプログラマが細やかなオプション指定は難しいのではないでしょうか？

……というわけで、昨今のC言語のコーディングの問題について、
人間の行動から導き出す妥当な解決手段は、大半は開発プロセス側(構文チェックをするとか)にあるんじゃないかなと思うのです。

Re:

[Anonymous Coward]

そういう救済措置を作ってしまうと、デスマーチな現場では結局「コンパイルが通れば万事いいんだよ」ですので、
構文チェックをスキップしたり、ワーニング抑制を入れて出荷するのが主流になるだけじゃないかなぁ。

最初から、仕様的に逃げ道が潰してある言語を渡したほうが、セキュアで利口だと思う。
自由度の高い言語は、研究・実験用途にはいいんですけど…

Re:

[Anonymous Coward]

use strict;
use warnings;

「私はふざけるのは嫌いですよ（わざとやるとき以外は）」