静的アナライザーはどのように、そしてなぜ偽陽性と戦うのか

前回の記事で、静的コードアナライザーが合成テストを使用して評価されるアプローチが気に入らないと書きました。 この記事では、警告が意識的に発行されない特別なケースとしてアナライザーによって認識された例を引用しました。 正直に言うと、このトピックに関するコメントが急増することはほとんどありませんでしたが、アナライザーに実装されている誤ったアラームカットオフメカニズムが原因でエラーに関する警告を出すことはありませんでした。 誤検知との闘いは静的アナライザーの非常に大きなコンポーネントであるため、ここで何を議論するのかさえ明確ではありません。 これを行う必要があり、それだけです。 このようなメカニズムは、アナライザーだけでなく、他のアナライザー/コンパイラにも存在します。 それにもかかわらず、この瞬間はそのような激しい議論を引き起こしたので、それに注意を払う価値があると思うので、この説明記事を書きました。

はじめに

それはすべて、「 なぜ合成テストが好きではないのか 」 という出版物から始まりました。 この記事は控えめに書かれたと言えるでしょう。 ディスカッションでは、特定の模擬テストが好きではない理由を説明する必要がある場合があります。 毎回長い答えを書くのは難しいので、私は長い間、記事への回答を準備することを計画していました。 itc-benchmarksを見たとき、テキストを書く良い時期であることに気付きました。私の印象は新鮮で、記事に含めることができるいくつかのテストを選択できます。



私はプログラマーのコミュニティによるこの記事のそのような拒否や、さまざまなサイトやメールでのコメントを期待していませんでした。 この理由は、おそらく、私が静的アナライザーを10年間開発しており、いくつかの質問が非常に明白に思えるため、それらをあまりにも簡潔かつカテゴリー的に考えるためです。 誤解を排除し、偽陽性との闘いが行われている方法と理由を説明します。



記事のテキストは任意のツールを参照できますが、PVS-Studioはそれとは何の関係もありません。 同様の記事は、GCC、Coverity、またはCppcheckの開発者の1人が作成できます。

誤検知を伴う手動操作

メイントピックに着手する前に、誤ったメッセージのマークアップを明確にしたいと思います。 何が起こっているのか理解せず、多くの人が否定的なコメントを書き始めたという印象を受けました。 私は次の精神でコメントに会いました：



あなたは間違った方法で行った。 誤検知を抑制するメカニズムを提供する代わりに、誤検知をできる限り排除しようとするため、多くの場合誤解されます。



このトピックの議論に戻らないように説明をします。 PVS-Studioは、どのような場合でも避けられない誤検知を排除するためのいくつかのメカニズムを提供します。

• コメントを使用して特定の行の警告を抑制します。
• マクロに起因する警告の大量抑制。 これも特別なコメントを通して行われます。
• 同様に、特定の文字シーケンスを含むコード行の場合。
• 設定または特別なコメントを使用して、このプロジェクトの無関係な診断を完全に無効にします。
• #ifndef PVS_STUDIOを使用したコードの一部の分析の例外。
• 特別な種類のコメントを使用して、一部の診断の設定を変更します。 それらは、特定の診断の説明で説明されています（例として、 V719 ：V719_COUNT_NAMEを参照）。

これらの機能はすべて、「 誤警告の抑制 」ドキュメントセクションで詳細に説明されています。 設定ファイルを使用して、警告をオフにしたり、マクロ内の警告を抑制したりすることもできます（pvsconfigを参照）。



それとは別に、特別なデータベースを使用してアラートの大量マーキングのシステムを強調する必要があります。 これにより、大規模プロジェクトの開発プロセスにアナライザーを迅速に統合できます。 このプロセスのイデオロギーについては、記事「 PVS-Studioアナライザーの使用方法 」で説明しています。



これはすべて、エラーと見なすべきでないものの明示的な指示を指します。 ただし、特別な例外を使用して警告を最小化するというタスクは削除されません。 アナライザーの価値は、すべてを誓うことではなく、誓う必要がない状況をどれだけ知っているかということです。

理論的背景

今少し理論。 各アナライザーの診断メッセージは、次の2つの特性によって評価されます。

• エラーの重大度（プログラムにとって致命的です）。
• エラーの信頼性（アナライザーが理解できないコードだけでなく、実際の欠陥が検出される確率）。

各診断のこれら2つの基準は、任意の割合で組み合わせることができます。 したがって、診断の種類を説明し、それらを2次元グラフに配置することが理想的です。

図1.診断は、重要度と信頼性によって評価できます。



いくつかの実例を示します。 * .cppファイルにコメントの見出しがないと判断する診断Aは 、右下隅に配置されます。 コメントを忘れても、プログラムでクラッシュすることはありませんが、コマンドで受け入れられるエンコーディング標準の観点からはエラーです。 この場合、コメントがあるかどうかを非常に正確に判断できます。 したがって、エラーの信頼性は高くなります。



クラスのメンバーの一部がコンストラクターで初期化されていないことを示す診断Bは、上部の中央に配置されます。 このエラーの信頼性はあまり高くありません。アナライザーは、このメンバーが初期化される方法と場所を理解できなかったためです（ これは困難です ）。 プログラマーは、コンストラクターの完了後に初期化を実行できます。 したがって、コンストラクター内の初期化されていないメンバーは必ずしもエラーではありません。 しかし、この診断はグラフの一番上にあります。これが本当に間違いである場合、プログラムのパフォーマンスに重大な影響を与えるからです。 初期化されていない変数の使用は重大な欠陥です。



アイデアが明確であることを願っています。 ただし、グラフ上のこのようなエラーの分布は認識しにくいことに読者は同意すると思います。 したがって、一部のアナライザーは、このグラフを9個または4個のセルの表に単純化します。

図2.簡略化された分類オプション。 4つのセルが使用されます。



たとえば、Goannaアナライザーの作成者は、Coverityが買収するまで行動しましたが、Synopsysは後に買収しました。 彼らは、アナライザーによって発行された警告を分類し、9つのセルのいずれかに関連付けました。

図3. Goannaリファレンスガイド（バージョン3.3）の一部。 9個のセルが使用されます。



ただし、この方法も珍しく、使用するには不便です。 プログラマーは、警告を1次元グラフ上に配置することを望んでいます。それは重要ではありません->重要です。 特に、異なるレベルに分けられたコンパイラ警告は同じ原則に基づいているため、これは一般的です。



2次元の分類を1次元に減らすことは簡単ではありません。 これは、PVS-Studioアナライザーで行ったことです。 単純に2次元グラフの下部がありません。

図4.重大度の高いアラートをライン上に投影します。 エラーは信頼性によって分類され始めます。



不正なプログラム操作につながる可能性のあるエラーのみを特定します。 ファイルの先頭にある忘れられたコメントは、プログラムのクラッシュにつながることはなく、興味深いものではありません。 しかし、これは重大なエラーであるため、クラスの初期化されていないメンバーを探しています。



したがって、信頼性のレベルに応じてエラーを分類する必要があります。 このレベルの信頼性は、3つのグループ（高、中、低）のアナライザーメッセージの分布にすぎません。

図5. PVS-Studioインターフェースウィンドウのフラグメント。 高および中レベルの一般的な診断の表示が含まれています。



さらに、アナライザーがエラーを検出して誤検知を与えなかったことをどの程度確信しているかに応じて、同じ警告が異なるレベルに分類される可能性があります。



同時に、すべての警告がプログラムにとって重要なエラーを探すことを繰り返します。 アナライザーが自信を持っていることもあれば、エラーを見つけたことが少ないこともあります。



ご注意 もちろん、一定の相対性があります。 たとえば、PVS-Studioには、V553という警告があります。アナライザーは、2000行を超えるコードの関数に遭遇したときに生成します。 このような関数にエラーを含める必要はありません。 しかし実際には、この関数がエラーの原因である可能性が非常に高くなります。 このような関数は、単体テストではテストできません。 コード内にこのような関数が存在することを欠陥と見なすことができます。 ただし、そのような診断はわずかであり、アナライザーの主なタスクは、配列境界の露出、未定義の動作、およびその他の致命的なエラーを検索することです（ 表を参照）。

誤検知と信頼水準

PVS-Studioの警告は、それが多かれ少なかれ重大なプログラムの誤動作につながると言えるコードフラグメントを検出します。 したがって、PVS-Studioの警告レベルはエラーの重大度ではなく、エラーの信頼性です。 ただし、レベルごとの分布については重要度を考慮することもできますが、全体像が重要であるため、このような小さな詳細については説明しません。



簡単に説明すると、レベルは特定されたエラーの信頼性です 。



前の記事で表明された批判は、誤った警告と戦う際に、有用な警告を失う可能性があるという事実に要約されました。 実際、警告は通常消えることはなく、信頼レベルに沿ってのみ移動します。 そして、読者が心配するこれらのまれなエラーオプションは、原則として低レベルで蓄積するだけであり、表示することはお勧めしません。 まったく意味のない警告のみが、完全に消えてしまいます。

図6.何かを準備しておくのは良いことです。 しかし、ある時点で停止する必要があります。



読者は有用なメッセージが消える可能性があると私の言葉で明らかに警告された。 それを否定する理由はありません。 このような確率は存在しますが、あまり重要ではないので心配する必要はありません。 これらのケースを考慮することは意味がないことを例で示します。 しかし、さまざまなレベルでメッセージを投稿するトピックから始めましょう。



場合によっては、どのレベルの信頼度で警告を発すべきかがすぐに明らかになります。 例として、次のエラーパターンを検出する簡単なV518診断を考えます。

char *p = (char *)malloc(strlen(src + 1));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最も可能性が高いのは、ブラケットを誤って配置したことです。 ターミナル0を配置する場所ができるように、1を追加したかったのです。 しかし、それらは誤っており、その結果、メモリは必要以上に2バイト割り当てられていません。



理論的には、プログラマーがまさにそのようなコードを書きたいと思っていたと想像できますが、この可能性は非常に小さいです。 したがって、この警告の信頼性は非常に高く、常に高レベルのメッセージに配置されます。



ところで、この診断には、単一の例外さえありません。 そのようなパターンが見つかった場合は、エラーです。



その他の場合、エラーの信頼性が低く、メッセージが常に低レベルに送信されることがすぐに明らかになります。 このような診断はほとんどありません。これは、診断が失敗したことが判明したことを意味します。 これらの愚かな診断の1つはV608であり、明示的なキャストで構成される重複シーケンスを検出します。 フォームの式が検索されます：

 y = (A)(B)(A)(B)x;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

なぜこの診断をしたのか覚えていません。 これまでのところ、この診断が本当の間違いを明らかにするのを見たことはありません。 彼女は冗長なコード（通常は複雑なマクロ）を見つけましたが、エラーは見つけませんでした。



ほとんどの診断は、実際のバグが見つかったというアナライザーの信頼度に応じて、レベルごとに「変動」します。



レベルを次のように解釈します。



高（最初のレベル）。 これはおそらく間違いです。 必ずこのコードをチェックしてください！ これが間違いでもない場合は、コードの記述が不十分である可能性が高いため、アナライザーや開発チームの他のメンバーを混乱させないように修正する必要があります。 例で説明します。

 if (A == B) A = 1; B = 2;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おそらくここにはエラーはなく、ブレースは必要ありません。 プログラマーが常に変数Bを2に設定したかったという可能性はわずかです。しかし、エラーがなくても、そのようなコードを書き直すことに誰もが同意すると思います。

 if (A == B) A = 1; B = 2;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

中（第2レベル） 。 このコードにはエラーが含まれているようですが、アナライザーにはわかりません。 すべての高レベルの警告を修正した場合、中レベルの警告を行使すると便利です。



低（第3レベル） 。 一般に学習に推奨しない低信頼度の警告。 プロジェクトのチェックに関する記事を作成するときは、高レベルと中レベルのみを考慮し、低レベルには連絡しないことに注意してください。



Unreal Engineプロジェクトに取り組んだときも、まったく同じことをしました。 私たちの目標は、一般目的の第1レベルと第2レベルのすべての警告を排除することでした。 私たちは第三レベルを見ませんでした。



前述したように、ほとんどの診断には、症状のセットに応じて異なるレベルを割り当てることができます。 一部の症状は減少するかもしれませんが、他の症状は自信を高めます。 これらは、100を超えるオープンプロジェクトでの診断の実行に基づいて経験的に選択されます。



診断がさまざまなレベルにどのように移行できるかを検討してください。 たとえば、疑わしい明示的な型変換を警告するV572診断を使用します。 new演算子を使用して、クラスのオブジェクトが作成され、そのポインターが別の型にキャストされます。

 T *p = (T *)(new A);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは奇妙なデザインです。 クラスAが Tから継承される場合、型変換は不要であり、単純に削除できます。 継承されない場合、これはおそらく間違いです。 ただし、アナライザーはこれが間違いであることを完全に確信していないため、最初に中程度の信頼レベルを割り当てます。 このデザインがどんなに奇妙であっても、正しく動作するコードに対応することがあります。 例を挙げることはできません。なぜなら、それがどんな状況なのか覚えていないからです。



要素の配列が作成されてから基本クラスへのポインターに変換される場合、これははるかに危険です。

 Base *p = (Base *)(new Derived[10]);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、アナライザーは高警告を表示します。 基本クラスのサイズは相続人よりも小さくすることができます。その後、 p [1]要素にアクセスするときに、「どこに行かないで取得し」、不正なデータを処理します。 基本クラスと相続人のサイズが同じ場合でも、このコードを編集する必要があります。 プログラマーは幸運になれますが、相続人クラスに新しいメンバーを追加することですべてを簡単に破ることができます。



同じ型への変換が発生すると、逆の状況が発生します。

 T *p = (T *)(new T);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなコードは、誰かがCを長時間使用していて、 malloc関数の呼び出しとは異なり、必須の型変換が不要であることを忘れたときに表示されることがあります。 または、古いコードをリファクタリングした結果、CプログラムがC ++プログラムに変わります。



ここにはエラーはなく、メッセージは完全に省略できます。 念のため、それは残りますが、低レベルに移動します。 このメッセージを見てコードを編集する必要はありませんが、誰かがコードに美しさをもたらしたい場合は気にしません。



前の記事へのコメントで、人々は警告が誤って消えることを心配していました。これは、低い確率ではあるが、エラーを示している可能性があります。 原則として、そのようなメッセージは消えませんが、低レベルに移動します。 調べた例の1つは、「T * p =（T *）（新しいT）;」です。 ここには間違いはありませんが、突然何かが間違っています...希望する人はコードを勉強できます。



別の例を見てみましょう。 V531診断：1つのsizeofを別のsizeofで乗算します：

 size_t s = sizeof(float) * sizeof(float);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは無意味な表現であり、おそらく、タイプミスなど、ここで何らかの間違いが行われた可能性があります。 アナライザーは、このコードに対して高警告を発行します。



ただし、警告レベルが[低]に置き換えられる場合があります。 これは、要因の1つがsizeof（char）の場合に発生します。



100を超えるプロジェクトで観察されたすべての式「sizeof（T）* sizeof（char）」はエラーではありませんでした。 ほとんど常に、それらはある種のマクロであり、そのような乗算は、あるマクロを別のマクロに置き換えるために得られました。



これらの警告は見ることができないため、低警告セクションでユーザーの目から隠されています。 しかし、希望する人はまだそれらを勉強することができます。

図7.読者は、低レベルのアラートの広大な領域をいつでも航行できることを知っています。

診断の例外

例外は、個々の診断と、診断のグループの両方に作用します。 「大量破壊の除外」から始めましょう。 プログラムには実行されないコードがあります。 実際、その中でエラーを探すことはできません。 コードが実行されないと、エラーは現れません。 したがって、多くの診断は非実行可能コードには適用されません。 これを例で説明します。

 int *p = NULL; if (p) { *p = 1; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポインターを間接参照する場合、可能な唯一の値はNULLです。 変数「p」に格納できる他の値はもうありません。 ただし、逆参照は実行されないコード内にあるという例外がスローされます。 そして、実行されないため、間違いはありません。 NULL以外の値が変数pに設定されている場合にのみ、逆参照が実行されます。



条件は常にfalseであることが通知されるので、誰かが警告が役立つと言うかもしれません。 しかし、これは他の診断、たとえばV547の懸念事項です。



上記のコードでnullポインターが逆参照されていることをアナライザーが警告し始めたら、誰かに役立つでしょうか？ いや



次に、診断の特定の例外に目を向けます。 以前にレビューしたV572診断に戻りましょう。

 T *p = (T *)(new A);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このメッセージが発行されない場合は例外があります。 そのようなケースの1つは、 （void）へのキャストです。 例：

 (void) new A();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブジェクトが作成され、プログラムの最後まで意識的に生きます。 このデザインは、タイプミスにより偶然に表示されることはありません。 これは、ビューの記録に関するコンパイラーとアナライザーの警告を抑制するための意識的なアクションです。

 new A();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多くのツールは、そのような設計を誓います。 コンパイラー/アナライザーは、人がnewオペレーターが返すポインターを書くのを忘れたことを疑います。 したがって、人々は意図的に void型にキャストを追加することで警告抑制を使用しました。



はい、このコードは奇妙です。 しかし、このコードをそのままにしておくように求められるので、これがあなたがする必要があることです。 アナライザーのタスクはエラーを探すことであり、コンパイラー/アナライザーを混乱させて警告を取り除くために、さらに洗練された構造を書くように強制することではありません。



とにかく誰かが警告を出すことは有用でしょうか？ いや このコードを書いた人は誰にでも感謝しません。



V531の診断に戻ります。

 sizeof(A) * sizeof(B)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

低レベルであっても、メッセージを送信しない場合がありますか？ はい、あります。



典型的なタスク：バッファーのサイズを計算する必要がありますが、そのサイズは別のバッファーのサイズの倍数です。 int型の125要素の配列があり、 double型の125要素の配列を作成する必要があるとしましょう。 これを行うには、配列要素の数にオブジェクトのサイズを掛ける必要があります。 それは、要素の数を計算するのが間違いを犯しやすい場合です。 したがって、プログラマーは特別なマクロを使用して、要素の数を安全に計算します。 これを行う理由と方法の詳細については、さまざまな記事に繰り返し書いています（ ここで arraysizeマクロの説明を参照してください）。



マクロを展開すると、フォームの構造が取得されます。

 template <typename T, size_t N> char (*RtlpNumberOf( __unaligned T (&)[N] ))[N]; .... size_t s = sizeof(*RtlpNumberOf(liA->Text)) * sizeof(wchar_t);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のsizeofは 、要素の数を計算するために使用されます。 2番目のsizeofは、オブジェクトのサイズを計算します。 その結果、すべてが正常であり、配列のサイズをバイト単位で正しく計算します。 おそらく読者は実際に議論されていることを理解していないでしょう。 謝罪しますが、物語の本質から逸脱して説明をしたくありません。



一般に、2つのsizeof演算子の乗算が完全に正常で予想される場合、いくつかの魔法があります。 アナライザーは、バッファーのサイズを計算するためのこのようなパターンを認識でき、警告を生成しません。



とにかく誰かが警告を出すことは有用でしょうか？ いや これは完全に正しく、適切に記述されたコードです。 だから書く必要があります。



続けましょう。 アナライザーは、フォームのデザインで警告V559を発行します。

 if (a = 5)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなコードの警告を抑制するには、式を二重括弧で囲む必要があります。

 if ((a = 5))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、アナライザーとコンパイラーにエラーがなく、条件内の値を意識的に適切にしたいというヒントです。 このようなヒントメソッドを誰がいつ作成したかはわかりませんが、多くのコンパイラーとアナライザーによって広く認識されサポートされています。



もちろん、PVS-Studioアナライザーは、このようなコードについても沈黙しています。



おそらく、警告を完全に抑制するのではなく、警告を低に移動する価値があったのでしょうか？ いや



人が間違った表現を誤って余分な括弧で囲む可能性はありますか？ はい、ありますが、非常に小さいです。 ブラケットを追加しますか？ そうは思いません むしろ、 ifステートメントごとに1000回発生します。 またはさらに少ない頻度。 したがって、余分なブラケットのためにエラーが見落とされる可能性は、1/1000未満です。



とにかく警告を出すほうがいいでしょうか？ いや したがって、コードからの警告を回避するための「合法的な機会」を人から奪いますが、追加のエラーを見つける可能性は非常に小さいです。



前回の記事のコメントで既に同様の議論を行っていますが、皆を納得させるものではありませんでした。 したがって、このトピックにもう1つの側面からアプローチしようとします。



すべての警告を見たいと主張する人々に質問があります。 ユニットテストを100％コードでカバーしましたか？ いや？ 間違いがあるかもしれないので、どうして？



サムは対戦相手に答えます。 テストでコードの100％をカバーすることは非常に難しく、高価です。 100％の補償に対して支払われる価格は、時間と労力の投資を返済しません。



これは、静的解析でも同じです。 交差点には、アナライザーの警告を分析する時間が妥当な制限を超える機能があります。 したがって、可能な限り多くの警告を発行する実用的な理由はありません。



警告V559が発行されない別のケースを見てみましょう。

 if (ptr = (int *)malloc(sizeof(int) * 100))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、メモリを割り当て、同時にメモリが割り当てられていることを確認するための古典的なパターンです。 ここに間違いがないことは明らかです。 男は明らかに書きたくなかった：

 if (ptr == (int *)malloc(sizeof(int) * 100))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この式には実用的な意味はなく、さらにメモリリークが発生します。 したがって、条件内での割り当ては、プログラマーがまさに望んでいたことです。



アナライザーがそのような設計について警告を発した場合、有益でしょうか？ いや



この章を例外の別の例で締めくくりましょう。これは正当化するのが難しいでしょうが、私たちの哲学を読者に伝えようと思います。



Diagnostics V501は、例外の数におけるリーダーの1つです。 ただし、これらの例外は、診断が効果的に機能することを妨げません（ 証明 ）。



診断は、次の形式の式に関する警告を発行します。

 if (A == A) int X = Q - Q;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

左右のオペランドが同一の場合、これは疑わしいです。



1つの例外は、演算 '/'または '-'が数値定数に適用されている場合、警告を発行しないことです。 例：

 double w = 1./1.; R[3] = 100 - 100;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

事実、プログラマーはそのような式を単純化せずに具体的に書くことがよくあります。 これにより、プログラムの意味を理解しやすくなります。 ほとんどの場合、このような状況は、多くの計算を実行するアプリケーションで見られます。



同様の式を持つ実際のコードの例：

 h261e_Clip(mRCqa, 1./31. , 1./1.);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような例外が原因で何らかのエラーをスキップできますか？ はい、できます。 ただし、誤検知を減らすことの利点は、有用な警告を失うことの潜在的な利点をはるかに上回ります。



このような除算または減算は、プログラミングの標準的な一般的な慣行です。 行為を失うリスクは正当化されます。



おそらく彼らはそこに別の表現を書きたかったのでしょうか？ はい、これは除外されません。 しかし、そのような推論はどこにも行かない道です。 「突然何か他のものを書きたかった」というフレーズは、1/31に適用できます。 そして、ここで私たちは、プログラムのすべての行に対して単純に連続して誓う理想的なアナライザーのアイデアに着きます。 空のものにさえ。 突然、それが空であるのは間違っています。 突然、関数foo（）を呼び出す必要がありました。

図8.停止できる必要があります。 そうしないと、診断の便利なウォークスルーがゴミになります。



会社にとって役に立たない1000を表示するよりも、1つの有用なメッセージを失う方が良いです。 これについて恐ろしいことは何もありません。 エラー検出の完全性は、アナライザーの有用性の唯一の基準ではありません。 同様に重要なのは、有用なメッセージと役に立たないメッセージのバランスです。 注意力はすぐに失われます。 多数の誤検知のあるレポートを見ると、人は警告に非常に無頓着になり始め、多くのエラーをスキップし、エラーではないとマークします。

もう一度簡単に例外について

私はすべてを詳細に説明したように思えますが、このタイプのコメントを再び聞くことができると思います：



機能とそれに対応するオン/オフボタンを作成するだけでなく、誤解について文句を言うべき理由がわかりません。 必要な場合は使用します。不要な場合は必要ありません。使用しないでください。 はい、これは仕事です。 しかし、はい、それはあなたの仕事です。

図9.すべてのフィルタリングアラートを無効にする設定を作成したいというユニコーンの反応。



例外をオフにして制限なしにすべての警告を表示するボタンを作成することをお勧めします。



このようなボタンはすでにアナライザーにあります！ あります！ 「低」と呼ばれ、最小レベルの信頼性で警告を表示します。



どうやら、多くは単に「例外」という用語を誤解しています。 例外として、問題を適切に診断するために、絶対に必要な多くの条件が作成されます。



これについては、 V519の診断に基づいて説明します。 値が同じオブジェクトに連続して2回割り当てられることを警告します。 例：

 x = 1; x = 2;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、この形式でのみ、診断は適用されません。 したがって、次のような改良が始まります。



例外N1。 オブジェクトは、=演算の右オペランドの一部として2番目の式に参加します。



この例外が削除されると、アナライザーは完全に正常なコードを誓います。

 x = A(); x = x + B();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

誰かがこの種のコードを見るために時間とエネルギーを費やしたいですか？ いや そして、私たちに反対を納得させることは失敗します。

主な考え

この記事では、誰かに何かを証明または正当化する目的はありません。 その目的は、読者の考えを正しい方向に向けることです。 アナライザーから可能な限り多くの警告を取得しようとすると、逆効果になると説明しようと思います。 これは、開発されたプロジェクトの信頼性を高めるのには役立ちませんが、プログラムの品質を改善するための代替方法に費やすことができる時間がかかります。



静的コードアナライザーは、すべてのエラーを検出することはできません。 また、他の機器も使用できません。 特効薬はありません。 ソフトウェアの品質と信頼性は、さまざまなツールを適切に組み合わせることで実現され、1つのツールで可能なことと不可能なことをすべて絞り出そうとすることではありません。



類推します。 彼らはさまざまな要素の組み合わせを使用して、建設現場で安全を達成しようとします。安全トレーニング、ヘルメットの着用、酔っている間は仕事を始めることの禁止などです。 1つのコンポーネントのみを選択し、すべての問題を解決することを期待するのは非効率的です。 内蔵のガイガーカウンターと毎日の給水で、素晴らしい装甲ヘルメットを作成できます。 しかし、これはすべて、高地での作業を行うときにあなたが落下することからあなたを救うわけではありません。 ここでは、別のデバイスが必要です-安全ケーブル。 ヘルメットに組み込まれたパラシュートの方向から考え始めることができます。 もちろん、これは興味深いエンジニアリング作業ですが、そのようなアプローチは実用的ではありません。 すぐに、ヘルメットの重量とサイズが合理的な制限を超えます。ヘルメットはビルダーに干渉し始め、彼らを怒らせ、仕事のペースを遅くします。ビルダーは一般的に、ひそかにヘルメットを脱ぎ、ヘルメットなしで作業を開始する可能性があります。



ユーザーがアナライザーのすべての警告を無効にした場合、信頼度がこれまでよりも低い警告をできるだけ多く表示しようとするのは不合理です。ユニットテストを実行し、コードカバレッジを最大80％にすると、さらに便利になります。100％のカバレッジを実装し、それを維持するのにかかる時間は、このアクションの利点を上回るため、100％のカバレッジを目指して努力する必要はありません。その後、動的コードアナライザーの1つをテストプロセスに追加できます。動的アナライザーが検出する一部のタイプの欠陥は、静的アナライザーを検出できません。そしてその逆。したがって、動的および静的分析は互いに完全に補完します。 UIテストを開発できます。



このような統合されたアプローチは、プログラムの品質と信頼性にはるかに良い影響を与えます。いくつかのテクノロジーを使用すると、テストでコード全体を100％カバーするよりも優れた品質を実現できます。同時に、コードの100％のカバレッジがはるかに多く費やされます。



実際、静的コードアナライザーからフィルター処理されていないメッセージをさらに必要としていると書いている人は誰も、同じコードアナライザーを使用したことはないと思います。または、エラーの密度が低いおもちゃプロジェクトで試してみた。実際のプロジェクトでは、常に問題、つまり既存の誤検知に対処する方法があります。これは、アナライザーの開発者とユーザーの両方が取り組む必要がある大きな課題です。さらに警告はどこにありますか？！



クライアントから1つまたは別の誤検知を排除するように依頼する手紙を定期的に受け取ります。しかし、私たちは聞いたことがない「より多くのメッセージを与える」。

おわりに

この記事から次のことを学びました。

1. PVS-Studioアナライザーは「臭い」を検索しませんが、プログラムの誤動作につながる可能性のある実際のエラーを検索します。
2. 診断メッセージは、3つの信頼レベル（高、中、低）に分けられます。
3. 高および中レベルのみを学習することをお勧めします。
4. 例外によって有用なエラーが削除されるのではないかと心配している人には、これはまずありません。ほとんどの場合、このような無効な警告は低レベルに移動されています。[低]タブを開いて、そのような警告を調べることができます。
5. 診断の例外は避けられません。そうでない場合、ツールはヘルプ以上の干渉を開始します。

このすばらしい記事を読むのに時間を割いてくれた皆さんに感謝します。私自身、そんなに長くなるとは思っていませんでした。これは、トピックが一見思われるよりも複雑であることを示しています。

ユニコーンは、プログラムコードの品質を引き続き保護します。幸運をお祈りします。また、「PVS-Studio 2017」のプレゼンテーションについてもご理解ください。





この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey Karpov。 静的アナライザーが誤検知と戦う方法と、なぜそうするのか