静的アナライザーの出力を処理する方法

Question

コードベースで静的アナライザー (Coverity) の使用を開始しました。私たちは受け取った警告の膨大な量 (その数は数十万件) にすぐに愕然としました。すべての警告をクリアするにはチーム全体で数か月かかります (当然のことながら不可能です)。

これまでに説明したオプションは次のとおりです

1) 請負業者に警告を整理して修正してもらいます。彼の欠点は次のとおりです。これらすべての変更を行うにはおそらく非常に経験豊富な人材が必要になるでしょうが、請負業者はコードを理解する必要はありません。

2) 警告をフィルターで除外し、危険なもののみに対処します。ここでの問題は、静的解析の出力が常に警告によって乱雑になり、問題を切り分けることが困難になることです。また、警告のフィルタリングも大きな労力です。

いずれにせよ、静的アナライザーが有用なツールとなり得る状態にコードをもたらすことは、途方もない作業のように思えます。

では、現在の開発作業を完全に停止させることなく、静的アナライザーをどのようにして使用できるのでしょうか?

Answer 1

まず最初にやるべきことは、分析設定を徹底的に調整することです。Coverity サポートにより、おそらくかなり一般的な構成が残されるでしょう。

• 欠陥の代表的なサンプルをトリアージし、チェッカーがノイズよりもはるかに多くの信号を生成しているように思われる場合は、当面はチェッカーをオフにします。(Coverity のチェッカーのほとんどは優れていますが、完璧なチェッカーは存在しません。徹底的な優先順位付けを行う必要があるようです。)
  • 長期的には、これらのチェッカーの一部をオンに戻しますが、レポートでは優先度が低いものとしてマークします。(これは思った以上に難しいです。私は長い間、Coverity は Dawson Engler と呼ばれる人物による欠陥ランキングに関する論文をいくつか読む必要があると主張してきました。:-)
  • さらに長期間実行する場合は、デフォルトで無効になっているチェッカーを試してください。中には印象的なバグを発見した人もいます。また、解析警告は驚くほど便利ですが、一部の偽の警告をオフにする必要があります。
• コードベースのどの部分を実際にすぐに修正するかについて、皮肉たっぷりに現実的になってください。少なくとも現時点では、コンポーネントを使用して、欠陥を修正する予定のないコードの分析をスキップします。(たとえば、理論的には、製品にサードパーティのコードが含まれている場合、製品の品質には責任があり、その製品のバグにパッチを適用する必要があります。実際には、そのようなバグが修正されることはほとんどありません。また、それが成熟したサードパーティのコードである場合、誤検知率が高くなります。)
  • コンポーネントと除外の設定は難しいですが、一度完了するとうまく機能します。私の否定先読み正規表現の 1 つは 100 を超える論理和を持っていました。
  • コンポーネントは、欠陥に対する個人の責任を割り当てるのにも役立ちます。これは、欠陥を修正するために非常に重要であることがわかりました。
• 新しい欠陥のみのレポートを設定し、その URL を見てもらいます。新しい欠陥はアクティブなコードに含まれるため、新しい警告なしポリシーを使用して開始する方が簡単です。

最後にいくつかの免責事項を述べさせていただきます。

• Coverity サポート フォーラム (http://forums.coverity.com/）、あまり活発ではありませんが、NDA に違反することを心配する必要はありません。有効にする価値があると判断したチェッカーのリストがそこにあります。

• 私は生計のためにこれをやっています、そしておそらくあなたは私たちを雇いたいでしょう(http://codeintegritysolutions.com/);今日はスタンフォード大学でこのテーマについて講演します。コンサルタントを雇ってチューニングを行うのは非常に理にかなっています。社外の誰かにトリアージをしてもらうのはさらに難しい。部外者に修正を依頼するのはさらに厄介です。間違いを修正することよりも、間違いから学ぶことがさらに重要です。

  • 私はこれを、スタンフォードでの講演の一部を企業ブログ用に少し拡張しました。 http://codeintegrity.blogspot.com/2010/01/handling-embarrassment-of-riches.html.

Answer 2

週に1日：分析をオンにします。 100回の最も厄介な警告を選びます。それらを修正。分析をオフにします。要するに：慌てる必要はありません。あなたのコードがそのまま動作します（それはしないのですか？）。一口サイズのチャンクで警告を介して動作ます。

あなたは警告の同じタイプは（悪いコーディングプラクティスを）再出現保つことが判明した場合、将来的にそれらを避けるために、あなたのチームを教育します。

私は古いコードベースでこれをやった：私は、コンパイラの警告/分析レベルをクランクアップ、（チームの残りの部分の前に）早朝に入るいくつかの警告を修正し、その後に戻ってそれを設定したいですデフォルトます。

Answer 3

1. レガシーコード用。これらの古いバグに優先順位を付けて、それらに対処する計画を立ててください。バグ修正と新機能開発のバランスをとります。新しい機能は常により重要です。
2. 新しいコード用。これを統合プロセスの一部にします。新しいコードをチェックインする前に、それらがカバーされていないことを確認してください。

Answer 4

あなたの請負業者のオプションについては、あなたはより緩やかなルートを行くAN彼らは唯一、明確なローカルであり、あなたのコードの完全な理解を必要としない問題を修正している場合があります。私は、コベリティのヒットの数が多いが、問題のコードを完全にローカルであり、何らの理解を必要としない簡単なチェックを固定することができ、バッファの終端を越え可能NULLポインタデリファレンスまたは可能な書き込みのようなものであることを推測すると思います大局ます。

私は認めるよ - 私はツールは、マイクロソフトから呼ばれているもののPREfast /プレフィックスまたはを使用する前に、このような仕事をしてきたが、その多くは、変化の機械的なものでした。請負業者または多分インターンに適しています。しかし、より多くの分析を必要とするものがあるでしょう - 。ただ、それは彼らが物事の奥深くに取得しようとしないことを請負業者（複数可）に明らかだことを確認します。

そして彼らにいいこと - それはドラッジの仕事なので、他のものは何でも楽しいことができることを確認します。

。

Answer 5

コベリティの人々は、あなたがそれを初めて使用するときに、すべての警告を「無視」に私たちに語りました。あなたは修正する必要があります。そして、次の微分のビルドでは、インクリメンタルに新しい警告を持つことになります。あなたは数ヶ月のためのツールを使用すると、あなたはそれに慣れて取得した後、あなたは戻って、古い警告を固定開始します。

Answer 6

他の静的解析器を試してみてください。私は、パラソフトC ++のテストで動作するように使用され、それが彼らの重大度に応じて警告をフィルタリングするための便利な方法を持っています。

Answer 7

それはあなたのニーズに合わせてカスタマイズに問題があるということですか？

として、

"" カスタマイズ可能な分析

コベリティ静的解析を微調整する能力を提供するが展開チェッカーの数、又はNULLポインタ逆参照するための閾値として、個々のチェッカーに固有の設定、のいずれかを変更することによって分析します。特定のコード・ブロック、またはアプリケーションのコベリティを設定する機能は、開発者がアプリケーションに最適なパフォーマンスのレベルを選択することを可能にし、より正確で信頼性の高い結果につながります。コベリティソフトウェア開発キットは、カスタムチェッカーを作成することにより、CおよびC ++コードでのユニークな欠陥タイプを検出することができます。これは、並行性、例外処理、およびその他の重要な問題を見つけるためのカスタムチェッカーを作成するだけである。「」
http://www.coverity.com/products/static-analysis.html

Answer 8

コベリティの典型的なアウトオブボックスの分析の構成は、コードの1000行あたり1と3の欠陥の間与える傾向があります。あなたは、欠陥の数十万人を持っている、とあなたはかなりのコードの100の未満万行を持っている場合、私はあなたの分析の設定が組織に正しくないか、次善であることを保証することができます。

チューニング分析の構成自体に加えて、あなたは衝撃で優先順位を付けることができます - デフォルトの「高」、「中」「低」のマッピングを使用すると、サブカテゴリになりがちいる感触を得るまでの作業を開始するのに十分な良いことがありますアプリケーションに最も有害ます。

第三には、あなたのコードベースが大きい場合（およびそのがされていない）開発の各チームやグループは、彼らが直接維持するだけのコードを見てみることができるようにコンポーネントにそれを細分化 - これはに仕事のより扱いやすいチャンクの両方を可能に処理し、それはまた、あなたがコンポーネント上で優先順位をつけることができます（サーバコードの欠陥は、クライアントコード、またはテストコード、またはサードパーティのコードなどの欠陥よりも重要です）。