「静的プログラム解析ツールの実力は？」記事へのコメント

出てくる警告にどう対処するのかが問題

[okky (2487)]

警告を無視したり、出てくる指摘に「逃げる」ようなコードで対処するプログラマばかりの世界では、まったく品質は向上しない。そして困ったことにそういう所こそ、品質を向上させなくてはいけない元凶だったりする。

# しかも、周りがヤイのヤイの言っても、今まで一度も直らなかったぐらい
# 上から下まで、ものを判っていない。

というわけで、このようなツールを使ったからどう、という事ではありません。
このようなツールの出力にどう対処するかが問題。また、このようなツールが
出してくる警告の量から、プログラム改善にかかる時間を正確に見積もる、などの
マネージメント能力も大事でしょう。

--
fjの教祖様

Re:出てくる警告にどう対処するのかが問題

[akiraani (24305)]

＞このようなツールの出力にどう対処するかが問題。

完成したコードにツールを通したあとで警告を減らすために修正するとけっこうひどいことになりますが、この手のツールに引っかからないようなコーディングスタイルを身に着けるというのはかなり有効ではないかと思います。

なので、製品のチェックに使用するなら、コーディング工程のかなり早い段階（クロスレビュー前）で使用し、既存のコードへの使用は傾向分析等を主にするのがいいんじゃないですかね。
これなら、逃げでごまかすよりも、警告の出にくいコードを書くようになると思うんですが。

--
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される

使う側の人間は少数派ですか？

[whelp (25685)]

静的解析ツールについては組み込み系の中の車両系では普通に用いられています。 使う理由としては

• 製品に不具合が発生すると最悪人命に関わる自体に発展するおそれがあるので可能な限り不具合を発見したい
• 人間では検査の質にムラが生じるが、ツールによる自動検査だとムラが生じない（新入社員でも、ベテラン社員でも一定の品質が確保できる）

などが上げられます。

特に近年、静的解析ツールに注目が集まっているせいか、ET2007でのチュートリアルセッション( http://www.jasa.or.jp/et/ET2007/conference/info_ts.html#TS-6 [jasa.or.jp])でもアイシン精機の方が講演中で静的解析ツールの導入・活用方法について触れられています。

私の知っているメーカーでは、静的解析ツールが出力した警告の報告・確認事項・対処（対策）法をマニュアル化して徹底させています。 しかし、静的解析検査はインフルエンザのワクチンのようなもので、一部の不具合の混入を防止するための手段の一つでしかなく、すべての不具合を検出できるわけではありません。 でも、最後は必ず複数の人間でコードレビューを行います。

また、車両系では製品を欧州に輸出するためには、開発プロセス中でMISRA-Cを用いなければならないようなので、選択したルールを満たしているかどうかの自動チェックにも用いています。

ツールを利用するタイミングですが akiraani さんが述べられているように、短時間で解析結果が出せるツールを

コーディング工程のかなり早い段階（クロスレビュー前）で使用

していますし、ツールによっては統合開発環境(Eclipse/HEW等）に組み込めるので、コンパイルの前にチェックを必ず行わせるようにしています。

また、検出率が高いが実行時間が長いツールも用いており、こちらは金曜日の夕方に解析を開始させると月曜日の朝のミーティングの前には結果が出ます。 そのため月曜日は検出された問題点に対する対処などを話し合っています。

ほかに、静的解析の他にもデッドロック発生の可能性やタイミングの正しさを確認するための動的解析環境の利用もマニュアルで指示されており、開発プロセス中でツールを用いるのが当たり前になっています。

----

（中に近い人なので話せる範囲で。）