プログラムの「ワーニング (警告)」メッセージはすべて潰すべき ? 122
ストーリー by reo
Wall 部門より
Wall 部門より
ある Anonymous Coward 曰く、
最近、他人が書いたソースコードを触る機会が多いのですが、気になるのがコンパイル時に発生する「ワーニング (警告) 」メッセージ。タレコミ子はプログラミング (C 言語) を習ったとき、「ワーニングはなるべく発生させないように」と教えられたのですが、ワーニングが出てもコンパイルは成功するし、多くの場合は意図したとおり動作するので、ワーニングを無視する人も多いようです。
個人的にはメッセージがうざいし、重要なエラーがワーニングに紛れて見にくくなってしまうので嫌なのですが、世の中的にはワーニングは無視してもよいものなのでしょうか ? まぁ、コンパイルオプションで抑制すればいいじゃん、という話ではあるのですが……。
そもそもWarningが出るということは,正しく記述されていない、と言うこと。 (スコア:5, 参考になる)
正しく記述されていない所には、
- typo (i と jとか)
- 型を根本的に理解し間違えている ( char * で受けるはずのものが int * になっているとか )
- ロジックが間違っている ( if ( i == j ) のはずが if ( i = j ) とか)
などの間違いが潜んでいるものです。つまり、そこをtypeしているときに、一瞬脳が寝ていた可能性がある。
Warningがどこで発生しているのかを調べたら「そこがそもそも正しく記述されているのか」「そこは何を意図しているコードなのか」を調査することで、多くのバグを事前に潰すことができます。
あるWarningを消す、というのは「そこを再検討してみましたが、やはり正しいようです」という意味でもあります。なので、Warningは限界まで消すべきなのです。
# まぁ、それでも結構バグってるしなぁ…
fjの教祖様
Re:そもそもWarningが出るということは,正しく記述されていない、と言うこと。 (スコア:5, 参考になる)
Cを使ったプログラミングの講義を担当していますが、学生には -Wall と -Werror の両方を付けて
コンパイルするよう指導しています。ときどき「この警告は必然なのです」と文句を言ってくる学
生もいるのですが、ほとんどは型をきちんと書けば出なくなるようなものばかりなので、正しい型
の書き方を教えれば納得してくれますね。
Re:そもそもWarningが出るということは,正しく記述されていない、と言うこと。 (スコア:1)
仕事でCでプログラミングしてますが、-Wallと-pedanticをつけるように決まっています。
バグの原因、教育によくない、メンテナンスの手間が増える、等の理由から警告は出来る限り潰すようにしています。
Re:そもそもWarningが出るということは,正しく記述されていない、と言うこと。 (スコア:1)
つけるオプションがプロジェクトで決まっているためそこまで考えたことありませんでした……。
その上-Oが必要な理由がわかりませんでしたorz
http://www.sra.co.jp/wingnut/gcc/gcc-j.html#Optimize%20Options [sra.co.jp]
ここを読んでみたんですが……。
Re:そもそもWarningが出るということは,正しく記述されていない、と言うこと。 (スコア:1, 参考になる)
警告について知りたいのなら、こちらを見るべきでは...
http://www.sra.co.jp/wingnut/gcc/gcc-j.html#Warning%20Options [sra.co.jp]
最適化を伴わない場合に出力されない警告があるので、-O などがないと片手落ちになる場合があります。
たとえば、以下のオプションが該当します。
Re:そもそもWarningが出るということは,正しく記述されていない、と言うこと。 (スコア:1)
おお、理解しました。
次のプロジェクトで提案してみます。
#1512801の方も#1512973の方もどうもありがとうございます。
でもバグって (スコア:5, すばらしい洞察)
警告がでてないところに潜んでるよね。
Re:でもバグって (スコア:2)
reinterpret_cast した時とか・・・．
Re:でもバグって (スコア:1)
Fortranなんかじゃ，implicit none とかで逆に何かあればすぐ警告を出すようにしてますけど，警告のないバグは潰せないですからね～．
!でも数値計算なんで，間違えが見つかりやすいのでそこまで深刻になったことはないですけど．
Re:でもバグって (スコア: -1, おせっかい) (スコア:1)
というのは「警告がでているところにバグは潜んでいない」という意味でもとれるので、あまり良い表現ではないかと。
# まあ、同感なのですが；；
お察しの通り、超濃緑茶です。 そう呼んだほうがいいでしょう。
Re:でもバグって (スコア: -1, おせっかい) (スコア:1)
コンパイラが吐き出すんだったら
バグとは呼べないやい!!
｡･ﾟ･(ﾉД`)･ﾟ･｡
潰すべき (スコア:3, すばらしい洞察)
お遊びや、ちょんプロなら無視しても問題が表面化しづらいと思いますが、大規模に開発するのであれば、潰しておくべきだと思います。
#・・・て、最近はスクリプト言語ばっかり書いてるんで、やってないです(汗
事態は際限なく悪化する。
ケースバイケース (スコア:2)
まぁたまに言語設計者もその周りも気にしてないのにろくにチームレビューも通ってなさそうな警告機能がついてて頭に来ることはありますが、コンパイルできて当たり前の所をエラーにされたり果ては core 吐かれたりすると仕事を中断して飲みに行きたくなります…
最低限「-Wall -Werror」 (スコア:2, すばらしい洞察)
「警告を消す」という感覚自体が問題だと思う。
最初から意図を含めて記述すれば-Wall程度では警告は出ない。
コンパイラに行間読ませるつもりでなければ-Wall程度の警告は出ないように書くべし。
わーにんぐじゃないよ。 (スコア:1, 参考になる)
うぉーにんぐ、だよ。
Re:わーにんぐじゃないよ。 (スコア:3, おもしろおかしい)
目くそ鼻くそ。
こんなのに「参考になる」なんて付けてんなよ。
Re:わーにんぐじゃないよ。 (スコア:2)
"warn" の母音部分の発音は "door" や "store" と同じで、発音としては「ウォー」と綴る方が絶対に近いです。少なくとも「アー」というように口を大きく広げる感じではありません。"door" や "store" を「ダアー」「スタアー」と書くように一貫していれば悪くもないかなと思いますが、そんな人はいまだかつて見たことはありません……。
Re:わーにんぐじゃないよ。 (スコア:2)
この手の話題では必ず発音の話になりますが、実のところワーニング派はローマ字読みしちゃっただけであることがバレバレなので、彼らの説にあまり説得力は感じられませんな。
ただ、通じるからいいじゃないかというのはまあその通り。なんかの拍子に海外に出たとき苦労しそうではありますが。
Re:わーにんぐじゃないよ。 (スコア:1)
ネイティヴの発音を聞いても、「わ」と「うぉ」のどちらが妥当か微妙な感じがします。この手のものは例外も山ほどあるし、どちらか一方が正しい、と言い切るのは無理では。
Warner Bros. は「ワーナー・ブラザーズ」と書く人がほとんどだし。
Re:わーにんぐじゃないよ。 (スコア:1, おもしろおかしい)
ワールですね、わかります。
ロボットじゃないよ。 (スコア:1)
アンドロイド、だよ。
に、空目した。
＃あれ？ 俺だけ！？
Re:わーにんぐじゃないよ。 (スコア:4, すばらしい洞察)
Re:わーにんぐじゃないよ。 (スコア:1, すばらしい洞察)
そもそも社会から信頼されてないから、概ね無害。
Re:わーにんぐじゃないよ。 (スコア:1, おもしろおかしい)
Re:わーにんぐじゃないよ。 (スコア:4, おもしろおかしい)
＞/.を./と書く人は信用できない
スラッシュドット内で「./」と書く場合は、
「ここ」という意味でokだって！
Re:わーにんぐじゃないよ。 (スコア:1)
そこのところは、どうなんでしょうか？
Re:わーにんぐじゃないよ。 (スコア:1, すばらしい洞察)
Re:わーにんぐじゃないよ。 (スコア:2, すばらしい洞察)
Re:わーにんぐじゃないよ。 (スコア:1, おもしろおかしい)
> HMX-12マルタイになるんですか。なんか強そう。
むしろ棒ラーメンにしか見えない。
Re:わーにんぐじゃないよ。 (スコア:1)
日本語で「警告」って言えばいいのにね。
Re:わーにんぐじゃないよ。 (スコア:1)
ロスト･イン･スペースはどうだったんだろう？
らうにん (スコア:3, 参考になる)
ブローニング・アームズという銃を作ってる会社があります。
でもこの「ブローニング」ってのは日本でしか呼ばれてないんですな。
綴りは「Browning」で、詩人のブラウニングと同じ発音をします。
大正期に日本に入ってきた「ぶらうにんぐ」の銃は「らうにん」の部分が「ろうにん」「ろーにん」に音便変化してしまい
すっかり「ブローニング」という呼び名が人口に膾炙してしまい今更ただしく「ブラウニング・アームズ社が…」とか言っても
「はぁ？お前ナニ言ってんの？」となってしまう始末
結論的にナニがいいたいのかっていうと、諦めろ。
Re:らうにん (スコア:2)
さういふことでございますか。
Re:らうにん (スコア:1, すばらしい洞察)
時間が許す限り排除すべき (スコア:1)
というか、極力排除したい。
ていうか、排除させて？ お願い（うるうるとした瞳で見つめる）。
ぐらいな感じ。
皆無にはできないけど、少なかったら少ないだけ気分いいし。
でも、ま、時間があったらね、じ・か・んが。
Re:時間が許す限り排除すべき (スコア:2, 興味深い)
自分の書いたソースは極力排除しています。
なんといっても手直しの時の気分が違うので。
また lint 世代なので
/* ARGSUSED */ , /* NOTREACHED */. /* FALLTHROUGH */
等、かならずコメントを付けています。
どうしても消せないものはその理由をソースに明記。
将来手直しするかもしれない自分へのメッセージですがら。
コンパイルでも警告レベルは最大、個別に警告を無効にするという
スタンスはなので、環境が変わるとしんどいですが。
コンパイラは言語に精通しているが、その処理対象には無知なので、
しょうがない奴だなあとやさしい気持ちで対応しています。
勿論バグを指摘される事の方が多いのですが、その後の話です。
理由があるから警告が出る (スコア:1, すばらしい洞察)
・警告として出たものは全て直さないといけない。
基本はこれだけの話だと思います。例外はありますが、その場合は例外であることを分かる様にしておくべき。
未使用の変数、フィールド (スコア:1)
パーサ・ジェネレータとかがよく出すんだけどユーザ側の努力では消せない…。
一概に言えない (スコア:1)
極端な話、漂流者発見のためのシミュレーションの最中だとしたらそんな些事にこだわるべからず。
ただし一般論としては、ウォーニングメッセージを全部つぶすくらいの余裕がある方が
幸せな職場なんだろうね。
Re:一概に言えない (スコア:1)
職人というのはほとんどの場合、見る眼のない客のために仕事をしているものだけれどね、
そういう客に調子を合わせて仕事をしてしまったら、職人の誇りの源泉をどこに求めれば
いいのだろう?
お節介なコンパイラなら (スコア:1)
if(NO_WARNING)
puts("WARNING: 本来の WARNING はなくなりましたが、ここまで \
WARNING つぶしに精を出すあなたは少し偏執狂的 \
です。健康に注意してください。");
Re:潰すか潰さないかじゃなくて (スコア:4, おもしろおかしい)
ありますね。
ワーニングもそうだし、より多く聞くのは：
Re:潰すか潰さないかじゃなくて (スコア:1)
**** おおっと! ****
よりも深刻度は低いからスルーしましょう
Re:潰すか潰さないかじゃなくて (スコア:2)
続く、メッセージが「テレポータ！」だったりすると、スルーできません
Re:潰すか潰さないかじゃなくて (スコア:1)
スルーできなくても、どうしようもならねぇよなあ
#仕事がロストしませんように・・・
Re:互換性 (スコア:2)
Re:互換性 (スコア:1, 参考になる)
しかし、VC9のC4996はコンパイルオプションに/D_CRT_SECURE_NO_WARNINGSをつけて無視する。
他プラットフォームとの互換性のために。
それならこんなのはどう？
#ifdef _MSC_VER
#if _MSC_VER >= 1500
#pragma warning(disable : 4996)
#endif
#endif
Re:絶対ダメっていう程でもない (スコア:2)
一般論というか、さすがに質問の意味は残す意味がないものでしょう。
それに、どうしても残す意味のある警告って、コンパイラの互換性の問題とかで、滅多にあることじゃないし。大抵はコーディングや設計で回避できるから。
Re:絶対ダメっていう程でもない (スコア:1)
C++ でメンバメソッドに throw(exception class) を付けると VC++ が「このバージョンのコンパイラじゃこれを指定しても意味がないぜ? hehe」と警告を出してくれます。
そして未だにこれを認識する VC++ のコンパイラは存在しません。
おかげで警告レベル最大は基本ですが、この警告を消すのも基本になったりします。
Re:潰したいのに潰せない警告 (スコア:1)
> ということで、使ってはいけないものだと思っていました。
コンパイラじゃなくて、デバッグシンボル。マングル名が長くなるテンプレート書くとすぐに件の警告が出るから、別にSTLの所為じゃない。