アカウント名:
パスワード:
「見てください、こんなに頑固な警告も機械的にキャストするだけで…ほら！」
静的解析ツールについては組み込み系の中の車両系では普通に用いられています。 使う理由としては
特に近年、静的解析ツールに注目が集まっているせいか、ET2007でのチュートリアルセッション( http://www.jasa.or.jp/et/ET2007/conference/info_ts.html#TS-6 [jasa.or.jp])でもアイシン精機の方が講演中で静的解析ツールの導入・活用方法について触れられています。
私の知っているメーカーでは、静的解析ツールが出力した警告の報告・確認事項・対処（対策）法をマニュアル化して徹底させています。 しかし、静的解析検査はインフルエンザのワクチンのようなもので、一部の不具合の混入を防止するための手段の一つでしかなく、すべての不具合を検出できるわけではありません。 でも、最後は必ず複数の人間でコードレビューを行います。
また、車両系では製品を欧州に輸出するためには、開発プロセス中でMISRA-Cを用いなければならないようなので、選択したルールを満たしているかどうかの自動チェックにも用いています。
ツールを利用するタイミングですが akiraani さんが述べられているように、短時間で解析結果が出せるツールを
コーディング工程のかなり早い段階（クロスレビュー前）で使用
また、検出率が高いが実行時間が長いツールも用いており、こちらは金曜日の夕方に解析を開始させると月曜日の朝のミーティングの前には結果が出ます。 そのため月曜日は検出された問題点に対する対処などを話し合っています。
ほかに、静的解析の他にもデッドロック発生の可能性やタイミングの正しさを確認するための動的解析環境の利用もマニュアルで指示されており、開発プロセス中でツールを用いるのが当たり前になっています。
（中に近い人なので話せる範囲で。）
int func(){ lock(); int r = func_body() ; unlock(); return r ;} int func_body(){ ... if(statement_stands) { return 1 ; } ... return 0;}
int func(){ lock1();... if (statement_stands) { unlock1(); return; }... lock2();... if (statement_stands) { /* ここでロックをはずすのを忘れる */ unlock1(); return; }... unlock2(); unlock1(); return;}
int func(){ lock1(); int r = func_body1() ; unlock1(); return r ;} int func_body1(){ ... if(statement_stands) { return 1 ; } ... lock2(); int r = func_body2(); unlock2(); return r;} int func_body2(){ ... if(statement_stands) { return 1; } ... return 0;}
ロック対象が増えた場合に見通しが悪くならね？
static int lfunc(){... if (statement_stands) { return; }...} int func(){ lock(); lfunc(); unlock();}
int func(){ int retcode = 0; do{ /* ==== 条件チェック ==== */ if(何かの条件){ retcode = -1; break; } /* ================ 処理本体 ================*/ }while(0); return retcode;}
returnがダメならgotoを使えばいいじゃない。
マジレスするとエンバグの危険を減らしてトータルの手間を減らすのが嬉しくて可読性を落とすのでしょう。 その規約によって実際に「エンバグの危険が減っているか」、あるいは「(誰かにとって)可読性が落ちているか」はまた別の話。
Emacsを使い続けているのは「最初の頃から使っているから」「慣れているから」などという理由ではなく、エディタとしてはEmacsの方が遙かに優れているからです。
少なくとも「美しくない」=「間違い」ではありません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
出てくる警告にどう対処するのかが問題 (スコア:5, すばらしい洞察)
# しかも、周りがヤイのヤイの言っても、今まで一度も直らなかったぐらい
# 上から下まで、ものを判っていない。
というわけで、このようなツールを使ったからどう、という事ではありません。
このようなツールの出力にどう対処するかが問題。また、このようなツールが
出してくる警告の量から、プログラム改善にかかる時間を正確に見積もる、などの
マネージメント能力も大事でしょう。
fjの教祖様
Re:出てくる警告にどう対処するのかが問題 (スコア:2, すばらしい洞察)
# みたいなー。
Re:出てくる警告にどう対処するのかが問題 (スコア:4, おもしろおかしい)
「わあ！見る見る消えていきますね！」
# 符号無し整数型の変数と負数のエラー定数を比較した、あの頃の記憶
Re:出てくる警告にどう対処するのかが問題 (スコア:3, おもしろおかしい)
警告が出た行を丸ごと削除するという荒技が・・・・
Re:出てくる警告にどう対処するのかが問題 (スコア:1, おもしろおかしい)
#「だってコンパイとおんないから」じゃねぇ
#仏の顔って何度までだっけ？ orz
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
だって、ほかからいろいろいじれた方が楽チンだっ、て思うんだもの。
ごめんなさい。ごめんなさい。
Re:出てくる警告にどう対処するのかが問題 (スコア:2, 興味深い)
そしてそういう人たちは、「何が問題なのか」をいくら説明しても馬耳東風なのです。
「で、どうすればいいって～～??!」
一瞬「この世から消えろ」と「プログラマ辞めろ」とどっちを先に言おうか悩んだのは秘密だ。
そして実際に言ったせりふは…
「… あぁ… どうやら天もあなたの今の発言には怒り狂ったようですね。
寝言は寝て言うように」
# fjの教祖様の怒りが頂点に達すると、雷が天から降り注ぐ…ときもあるのだ。
fjの教祖様
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
いやいや普通なら、
「Warnningは全部消せ。」
「消せないなら、消せない理由を報告書を書いて出せ。」
って、いっておくだけで、
みんな必死にシンタックスな問題からセマンティックな問題に昇華してくれます。
書類、書くの嫌いだから。
セマンティックな問題は、コードレビューしか対処方法はないですよね？
コードレビューは、レビュアという教育者を育てるし、
プログラマ教育の教材そのものではないですか。
バグはでるものと割り切って、バグを多く出すレビュアを、
首にするなり、再教育するなり、調教するなり、
そこまできたらマネージャー自由にしてもいいですよね。
# という、牧歌的な時代はとうの昔に終わってましたか。そうでしたか。
Re: (スコア:0)
それを聞くのなら暖かく見守ってあげてください。
こっちはこんな感じです。
「でも動くじゃん」
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
何せ向上心が皆無な状態では何を教えても無駄なんだから。
もっとも、その「何が問題なのか」には「半年後くらいの夜中に呼び出されてもう忘れちゃってるコードと格闘して、稀にしか再現しないバグを追う羽目になる...こともある」とか、メカものなら「暴走して人死にが出る...こともある」あたりまで含まれてないとわかってもらえないかもしれないけど。
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
the.ACount
Re:出てくる警告にどう対処するのかが問題 (スコア:2, すばらしい洞察)
完成したコードにツールを通したあとで警告を減らすために修正するとけっこうひどいことになりますが、この手のツールに引っかからないようなコーディングスタイルを身に着けるというのはかなり有効ではないかと思います。
なので、製品のチェックに使用するなら、コーディング工程のかなり早い段階（クロスレビュー前）で使用し、既存のコードへの使用は傾向分析等を主にするのがいいんじゃないですかね。
これなら、逃げでごまかすよりも、警告の出にくいコードを書くようになると思うんですが。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
使う側の人間は少数派ですか？ (スコア:3, 興味深い)
静的解析ツールについては組み込み系の中の車両系では普通に用いられています。 使う理由としては
- 製品に不具合が発生すると最悪人命に関わる自体に発展するおそれがあるので可能な限り不具合を発見したい
- 人間では検査の質にムラが生じるが、ツールによる自動検査だとムラが生じない（新入社員でも、ベテラン社員でも一定の品質が確保できる）
などが上げられます。特に近年、静的解析ツールに注目が集まっているせいか、ET2007でのチュートリアルセッション( http://www.jasa.or.jp/et/ET2007/conference/info_ts.html#TS-6 [jasa.or.jp])でもアイシン精機の方が講演中で静的解析ツールの導入・活用方法について触れられています。
私の知っているメーカーでは、静的解析ツールが出力した警告の報告・確認事項・対処（対策）法をマニュアル化して徹底させています。 しかし、静的解析検査はインフルエンザのワクチンのようなもので、一部の不具合の混入を防止するための手段の一つでしかなく、すべての不具合を検出できるわけではありません。 でも、最後は必ず複数の人間でコードレビューを行います。
また、車両系では製品を欧州に輸出するためには、開発プロセス中でMISRA-Cを用いなければならないようなので、選択したルールを満たしているかどうかの自動チェックにも用いています。
ツールを利用するタイミングですが akiraani さんが述べられているように、短時間で解析結果が出せるツールを
していますし、ツールによっては統合開発環境(Eclipse/HEW等）に組み込めるので、コンパイルの前にチェックを必ず行わせるようにしています。また、検出率が高いが実行時間が長いツールも用いており、こちらは金曜日の夕方に解析を開始させると月曜日の朝のミーティングの前には結果が出ます。 そのため月曜日は検出された問題点に対する対処などを話し合っています。
ほかに、静的解析の他にもデッドロック発生の可能性やタイミングの正しさを確認するための動的解析環境の利用もマニュアルで指示されており、開発プロセス中でツールを用いるのが当たり前になっています。
----（中に近い人なので話せる範囲で。）
Re:出てくる警告にどう対処するのかが問題 (スコア:1, 興味深い)
中でも最凶最悪なのは、関数の途中での return 禁止というものです。
枝刈りして関数を抜けたいのに、フラグを引き回して入れ子が深くなって読みづらいのです。
なにが嬉しくて可読性を落とすのか。教えて！エロイひと！
Re:出てくる警告にどう対処するのかが問題 (スコア:3, 興味深い)
int func()
{
lock();
...
if (statement_stands)
{
/* ここでロックをはずすのを忘れる */
return;
}
...
unlock();
return
}
とか．
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
Re:出てくる警告にどう対処するのかが問題 (スコア:1, 参考になる)
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
ロック対象が増えた段階で、プログラム上、無理がなければ、すぐに関数を分けてしまう方なので、あまり気にならないなぁ。
lock1();
...
lock2();
...
unlock1();
...
unlock2();
のような場合は1つで書かざる得ないが。
(でも、こういう例では、途中から抜けるような処理はご法度かなぁ。)
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
そして、重箱の隅(Re:出てくる警告にどう対処するのかが問題) (スコア:0)
って書いたんだから、
> return;
に、リターンコード指定しようよｗ
Re:そして、重箱の隅(Re:出てくる警告にどう対処するのかが問題) (スコア:1)
Re: (スコア:0)
ついでに、
もし、C++で書いているんだったら、lock unlockはデストラクタで解決してくれと思う。
Cで書いているなら、 do{ }while(0); でがんばるか、エラー部分だけは例外的に goto err で抜けるとかがいいと思う。
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
struct DoUndoLock {
DoUndoLock() { lock(); }
~DoUndoLock() {unlock(); }
}
void func()
{
DoUndoLock locker;
...
if (statement) {
...
return;
}
...
return;
}
みたいな．
Re:出てくる警告にどう対処するのかが問題 (スコア:2, 興味深い)
MISRA-Cってのは自分で適切なルールを選んで適用するものです。
ですから、関数途中のreturnを禁止するとうまくない理由をちゃんと説明して
そのルールを外してもらうのがMISRA-Cのやり方です。
外してもらえないのなら、あなたの説明が悪いか、ボスand/or顧客がアレなのか、どちらかあるいは両方です。
MISRA-Cは正しいのですｗ
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
メモリリークやハンドルリークなんかは場所の特定がたいへんに面倒なので、コーディングレビューで出来るだけ潰しておきたいというのは考え方としてはありだと思うけど。
クラス使ってるとデストラクタでカバーできるんでかまわないんでしょうけど、組み込みではそうもいきませんし。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:出てくる警告にどう対処するのかが問題 (スコア:1, 興味深い)
＃最初に見たとき意味わかんなくて「このループ必要ないよね」と思ってがしがし書き換えてました。
Re: (スコア:0)
IDEではない場合や、まったく知らない人のコードを読む場合はわりとよみやすいこともあります。
最も変数宣言が関数の上のほうにかならずあること、というのが前提ですがスタックサイズを把握しやすいのでこれはこれでありだとは思います。
親コメントの話している層だとそもそもC言語が適していないものだと思われます。
Re: (スコア:0)
returnがダメならgotoを使えばいいじゃない。
マジレスするとエンバグの危険を減らしてトータルの手間を減らすのが嬉しくて可読性を落とすのでしょう。 その規約によって実際に「エンバグの危険が減っているか」、あるいは「(誰かにとって)可読性が落ちているか」はまた別の話。
そういや先日も (スコア:1)
署名スパムがウザい？アカウント作って非表示に設定すればスッキリさ。
Re: (スコア:0)
>このようなツールの出力にどう対処するかが問題。
「素晴らしい洞察」ですな。
Eclipseなんかのツールを使う人の中には酷いコードを書く人も少なくないけれど、
新人に適切な対処の仕方を教えるためには、Emacsみたいな単純なエディタを使った
方が教育効果が高いのかも。
Re: (スコア:0)
プログラム力とは違うが、自分に合ったツールを見繕う力も必要だと思う。
Re: (スコア:0)
Re:出てくる警告にどう対処するのかが問題 (スコア:2, すばらしい洞察)
.
年をとってもコーディングを続けられる(続けざるを得ない、ではなくね)人たちの多くは「最初の頃からずっと使い続けられているエディタ」である Emacs や vi を使っている人が多いと思います。
# 私も Final を一時期使っていたが、結局それらは生き残らなかった…
一方で、若い人たちの多くは Eclipse を使っているでしょう。
と言うことは、単純に考えても Eclipse 側には「若手が多い」というバイアスがかかります。
プログラミングもやはり経験値がある程度ものを言いますので、「若手が多い」環境はどうしても品質が下がる、という傾向が出てしまいます。
コーディングを「できなくなる」人たちと言うのは、レベルが低い側ほど脱落率が高いでしょう。と言うことは、同じ世代のプログラマは年齢が上がるほど、平均レベルが高くなるはずです。
.
と言うわけで、20年ほど前に「vi/Emacsなんか使っている奴らのコードは使い物にならん」と言われたのと同じ意味において、今の Eclipse 使いのコードは醜い側に広く分布していると思われます。あと20年もすれば Eclipse よりも便利なツールが現れて新人はみなそちらを使うようになり、きっと言うようになるでしょう。
『xxxx を使っている奴らのコードは醜くていかん』
fjの教祖様
Re:出てくる警告にどう対処するのかが問題 (スコア:2, すばらしい洞察)
>「最初の頃からずっと使い続けられているエディタ」である Emacs や vi を使っている人が多いと思います。
多くかどうかは知らないけど、Emacsを使ってる人はEclipse『も』使ってる人が結構いますよ。
Emacsを使い続けているのは「最初の頃から使っているから」「慣れているから」などという
理由ではなく、エディタとしてはEmacsの方が遙かに優れているからです。
＃Eclipseは統合環境である以上はエディタが貧弱なのは当たり前。
より適切な道具を取捨選択して使った結果、今でもエディタにはEmacsを選択する。
それだけのことです。
>と言うことは、単純に考えても Eclipse 側には「若手が多い」というバイアスがかかります。
あまりに単純化しすぎでは。
上にも挙げたように、Emacsを使ってる人がEclipseも使っていることが多々あります。
Eclipseから入った若手でも、（おそらくごく一部ではあるが、）Emacsを使ってる人もいます。
＃中にはずっとメモ帳でやってきて、最近になってやっとEclipseを覚えた
＃『経験豊富な熟練者』もいるかもしれないけど、一緒にやってくのには不安を覚える。
Eclipseから入り、そしてそれ以外を知らない人の中には、自分では何も考えず、ツール
が出す指示に従って切り張りする人がいます。それでエラーは出なくなるし、コンパイルも
通ります。でもそれはプログラミングと呼ばれる作業とは全く異なるものでしょう。
エディタは(たとえそれがEmacsであっても)何も指示してくれないので、自分で考えない人、
考えられない人は最初の段階で躓きます。またそれを自分で自覚できます。何が分かって
ないのかに気付くことが、学習への第一歩です。
便利すぎる道具は、初心者が学習する時には逆効果になりかねません。
Re:出てくる警告にどう対処するのかが問題 (スコア:1, 興味深い)
そしてemacsもVSもマクロガリガリ使いますし、Eclipseに至っては独自のプラグインも作ります（それがマクロと同じ意味だから）
ここが肝心な点ですがキーバインドは全部Emacsなんです、要するにアタマで使う部分（機能）と体が覚えた部分（キーバインド）ってのは別の話なんです。(VSのキーバインドをemacsにするためにxemacsから全面的にマクロを使って割り当て直しにしたせいでVS2003,2005,2008と全部個別に対応する羽目になったけど)
#他人が自分のVSを使うとパニックになるように、僕がまっさらのVSを使うとプリンターダイアログが
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
多数こそが全体の傾向を決めるのであって、「例外」が少々いても、全体の傾向には影響しない。
# Emacs が優秀である? 知ってるよそんなの。
# しかし、それでも Eclipse 使いの大半は Emacs 使い「ではない」のだよ。
fjの教祖様
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
fjの教祖様
Re: (スコア:0)
今、そのシステムはインフラの一部としてまだ稼動しているようです。
# さすがにAC。
Re:出てくる警告にどう対処するのかが問題 (スコア:1, おもしろおかしい)
Re:出てくる警告にどう対処するのかが問題 (スコア:1, すばらしい洞察)
少なくとも「美しくない」=「間違い」ではありません。
顧客の「デーモンがcoreを吐く」という要望に対しては
- 美しいが高コストな方法： デバッグ、ソースコードの修正を行い、coreを吐かないようにする
- 美しくないが低コストな方法: coreを吐いても、coreファイルを保存しないようにする
という感じで、複数の選択肢があります。
ここで後者の低コストな方法で顧客が満足してくれるのなら、何も問題はないと思います。
# 本来は、ちゃんと顧客に複数の選択肢があることを説明した上で、どちらか一方を提案するべきですが。
Re:出てくる警告にどう対処するのかが問題 (スコア:1)
これはあちらこちらで何度も聞くが、じゃぁ「間違っていないコード」を見るとたいてい「美しい」。
醜いコードが醜くなるのは、例外の固まりになるから。そして例外だらけのロジックは大抵煩雑で(複雑ではなく煩雑で)、人間の誤りを誘発する。しかも例外ケースは滅多に走らないため、『動いているシステム』であってもバグを内包したままである確率はきわめて高い。
もちろん、そのようなコードが「あとどれぐらい使われるのか」によっては、直すコストより放置して問題が起こったときに対処するコストの方が安い(期待値として)と判断されるかもしれない。しかし、それは「障害対策コスト」と「障害発生確率」から算出されるべきであって、
『醜くても動いているんだからいいじゃん。直すのにコストかかるし』
は、さすがによくない。
fjの教祖様
Re: (スコア:0)
・処理に失敗するのはかまわないが、ディスク容量を食うのは困るらしい
という条件の下で似たような対処をやったことはある。
＃開発部に上げても「要求仕様に沿ってない状況での不具合には対応する必要はない」という
＃回答しか返ってこないし。
いまだにC/C++を使っているのが問題 (スコア:0)
何故ならばC/C++以外のプログラミング言語を知っている人が死滅してしまったから．
しかし過去のしがらみを根底からひっくり返すようなことは誰もしないし，出来ないので，
対症療法的な手法に頼るしかないのは悲しい．
産学協同がうたい文句の研究やらざるをえない大学の研究室なら，組込専用の新プログラミング
言語開発なんかやってみても面白いと思うんだけどね．
Re:いまだにC/C++を使っているのが問題 (スコア:2, すばらしい洞察)
C/C++が採用される(活かされる)のだと思いますが。
問題と思うなら何が問題で、言語にどのような仕様があれば解決するのか
説明して頂けないでしょうか。
＃こういうことを尋ねると大概ライブラリの問題など言語に関係ない方向に進む。
Re: (スコア:0)
後は以下のループ
とりあえず使える技術者がいるから、メーカーが処理系を用意する。
処理系が用意されているから、みんなCで書く。
誰かもっとまともな処理系を小ピンマイコンから64bitまで用意してくれないかな。
最適化と移植性に考慮してくれたらうれしい。
Re: (スコア:0)
神は言われた。「プログラムがなくてはただの箱だ。開発言語あれ！」アセンブラが生まれた。第二の日である。
神は言われた。「アセンブリ言語はややこしいな。高級言語あれ！」こうしてC言語が生まれた。第三の日である。
神は言われた。「一人では限度がある。プログラマーあれ！」こうしてたくさんのCのプログラマーが生まれた。以来彼らのその作業は、復活の日まで終わることのないものとなった。第四の日である。
神は言われた。「プログラマーよ、開発せよ！」こうしてプログラムが完成した。第五の日である。
神は言われた。「さあ動け！」だがバグだらけで動作しなかった。第六の日である。
納期は訪れた。「探さないで下さい」第七の日に、神はご自分の仕事を離れ安息された。
Re:いまだにC/C++を使っているのが問題 (スコア:4, おもしろおかしい)
Re:いまだにC/C++を使っているのが問題 (スコア:1)
Re: (スコア:0)
死滅した人たちがどのようなプログラミング言語を知っていたかに興味あります。
Re:諦めの境地 (スコア:1)