異なるコードアナライザーをユーザー間で比較したいというユーザーの要望は理解可能で自然です。 しかし、この欲求を実現することは、一見すると思えるほど単純ではありません。 事実は、どの特定の要因を互いに比較するのかが明確ではないということです。
「診断されたエラーの数を比較する」または「ツールが発行したメッセージの数を比較する」などのまったくばかげたアイデアを破棄する場合、合理的なパラメーター「信号対雑音比」でさえ、コードアナライザーを評価するための理想的な基準ではないようです。
これらのパラメーターを比較しても意味がないことを疑いますか？ 以下に例を示します。
どのパラメーターが単に比較する意味がないか
診断チェックの数など、一見単純な特性を考慮してください。 多いほど良いようです。 しかし、特定のオペレーティングシステムとコンパイラのセットを使用するエンドユーザーにとって、ルールの総数は何の意味もありません。 彼が使用しないシステム、ライブラリ、およびコンパイラに関連する診断ルールは、彼に何も与えません。 構成システムとドキュメントが乱雑になり、ツールの使用と実装が複雑になります。
ここでは、次の例えが関連しています。 男が店に来てヒーターを買います。 彼は家電部門に興味があり、この部門に大きな選択肢がある場合、これは良いことです。 しかし、他の部門は彼にとって面白くない。 この店でインフレータブルボート、携帯電話、椅子を購入できれば、何も問題はありません。 しかし、膨脹可能なボートの部門の存在はヒーターの範囲を改善しません。
たとえば、エキゾチックなシステムを含む多種多様なシステムをサポートするKlocworkツールを取り上げます。 これらのシステムの1つには、次のコードを「飲み込む」コンパイラーがあります。
インラインint x;
Klocworkアナライザーには、コードでこの異常を検出できる診断メッセージがあります：「 'インライン'キーワードは、関数またはメソッド以外のものに適用されます」。 そのような診断があるのは良いようです。 しかし、たとえば、Microsoft Visual C ++コンパイラーまたは別の適切なコンパイラーを使用している開発者には、この診断の利点はありません。 Visual C ++は、このようなコードを単にコンパイルしません。「エラーC2433： 'x'： 'inline'はデータ宣言で許可されていません」。
別の例。 一部のコンパイラは、bool型を十分にサポートしていません。 そのため、Klocworkは、クラスメンバーがbool型の場合、「PORTING.STRUCT.BOOL：このチェッカーは、構造体/クラスにboolメンバーがある状況を検出します」という状況について警告できます。
彼らは教室で愚か者を書いた、それは恐ろしいことだ...開発者のごく一部がそのような診断メッセージから利益を得ることができるのは明らかだ。
多くの同様の例があります。 また、診断ルールの総数は、特定のプロジェクトでアナライザーが検出したエラーの数とは関係がないことがわかりました。 100個の診断を実装し、Windowsアプリケーション向けのアナライザーは、Microsoft Visual Studioでコンパイルされたプロジェクトで、1000個の診断を実装するクロスプラットフォームアナライザーよりも多くのエラーを見つけることができます。
そのため、診断ユーティリティの数を診断チェックの数などのパラメーターで比較することは不可能であることがわかりました。
「それでは、特定のシステムに関連するチェックの数を比較しましょう。 たとえば、Windowsプログラムのエラーを検索できるすべてのルールを選択します。」 ただし、このアプローチは次の2つの理由で機能しません。
第一に、あるアナライザーではチェックが1つの診断ルールによって実装され、別のアナライザーではいくつかのルールによって実装されることがよくあります。 また、診断ルールの数で比較すると、検出されたエラーの点では同一ですが、アナライザーのいずれかが優れているようです。
第二に、特定の診断の実装は異なる品質になる可能性があります。 たとえば、ほとんどすべてのアナライザーは「マジックナンバー」を検索します。 しかし、たとえば、一方のアナライザーでは、64ビットシステム（4、8、32など）へのコード転送の観点から危険なマジックナンバーのみが検出され、もう一方では-すべてのマジックナンバー（1、2 、3など）。 そして、単に「マジックナンバーの検索」列の比較表で、あちこちに配置するには、「プラス」では十分ではありません。
また、ツールの速度や1分あたりのコードの処理行数などの特性を提供することも好みます。 しかし、それでも実用的な意味はありません。 コードアナライザーの速度とプロジェクトの人間による分析の速度との間に関係はありません！ まず、多くの場合、夜間分析中にコード分析が自動的に起動されます。 そして、朝の前に「キャッチ」することが重要です。 そして、第二に、使いやすさなどのパラメーターについて比較するとき、彼らはしばしば忘れます。 ただし、この問題をより詳細に処理しましょう。
適切に比較するには、ツールの使いやすさが非常に重要です。
実際、コードアナライザーの実際の使用における非常に重要な役割は、ツールを使用するのがいかに便利であるかによって決まります...
最近、2つのコードアナライザーでeMuleプロジェクトをテストし、この操作の利便性を評価しました。 それらの1つは、Visual Studioのいくつかのエディションに組み込まれた静的アナライザーでした。 もう1つはPVS-Studioです。 また、Visual Studioに組み込まれたコードアナライザーを使用する際に、いくつかの問題がすぐに見つかりました。 さらに、これらの問題は、分析の品質と速度には関係ありません。
最初の問題は、アナライザーからのメッセージのリストを保存して、さらに処理することができないことです。 たとえば、組み込みのeMuleアナライザーで確認すると、2,000件のメッセージを受け取りました。 一度にすべてを慎重に処理することは不可能なので、数日以内にそれらに戻らなければなりません。 ただし、分析結果を保存できないため、毎回プロジェクトを再確認する必要があり、非常に面倒です。 PVS-Studioでは、分析結果を保存して、後で作業に戻ることができます。
2番目の問題は、重複するアナライザーメッセージの処理の実装方法に関連しています。 ヘッダーファイル（.hファイル）の問題を診断することです。 アナライザーに、10個の.cppファイルに含まれている.hファイルの問題を検出させます。 これらの10個の.cppファイルのそれぞれを分析することにより、Visual Studioに組み込まれたアナライザーは、.hファイルの問題に関する同じメッセージを10回表示します！ 具体例。 eMuleメッセージを確認するとき
c：\ users \ evg \ documents \ emuleplus \ dialogmintraybtn.hpp（450）： 警告C6054：文字列 'szwThemeColor'はゼロで終了しない場合があります。 行：434、437、438、443、445、448、450
10回以上発行されました。 このため、分析結果が乱雑になり、ほとんど常に同じメッセージを確認する必要があります。 PVS-Studioでは、最初から重複メッセージは表示されませんでしたが、フィルタリングされたと言わなければなりません。
3番目の問題は、システムファイルの問題に関するメッセージを発行することです（フォームC：\ Program Files（x86）\ Microsoft Visual Studio 10.0 \ VC \ includeのフォルダーから）。 Visual Studioに組み込まれたアナライザーは、システムヘッダーファイルのブランド化については恥ずかしがり屋ではありませんが、これにはあまり実用的な意味はありません。 繰り返しますが、例です。 eMuleをチェックすると、システムファイルに関する同じメッセージが何度も見つかりました。
1> c：\プログラムファイル（x86）\ microsoft sdks \ windows \ v7.0a \ include \ ws2tcpip.h（729）： 警告C6386：バッファーオーバーラン： '引数1'にアクセスしています、 書き込み可能なサイズは「1 * 4」バイト、 しかし、「4294967272」バイトが書き込まれる可能性があります。 行：703、704、705、707、713、714、715、720、 721、722、724、727、728、729
とにかく、誰もシステムファイルを編集しません。 では、なぜそのようなファイルを「誓う」のでしょうか？ PVS-Studioはシステムファイルを決して誓いませんでした。
これには、マスクによって特定のファイルをスキャンしないことをツールに示すことができないことも含まれます。 たとえば、すべてのファイルは「* _generated.cpp」または「c：\ libs \」です。 PVS-Studioでは、除外ファイルを指定できます。
4番目の問題は、コードアナライザーからのメッセージリストの実際の作業に影響します。 もちろん、コードアナライザーでは、コードごとに診断メッセージを無効にできます。 今だけ、さまざまなレベルの便利さでこれを行うことができます。 より正確には、問題はコードによって余分なメッセージを隠すために分析を再開する必要があるかどうかです。 Visual Studioのコードアナライザーで、プロジェクト設定の切断されたメッセージのコードを書き換えてから、分析を再開する必要があります。 同時に、もちろん、すべての「余分な」診断をすぐに示すことができる可能性は低いため、再起動を数回繰り返す必要があります。 PVS-Studioでは、再起動せずにコードでメッセージを簡単に非表示および表示でき、はるかに便利です。
5番目の問題は、コードだけでなくテキストでもメッセージをフィルタリングすることです。 たとえば、「printf」を含むすべてのメッセージを非表示にすると便利です。 Visual Studioに組み込まれているアナライザーにはこのような可能性はありません。PVS-Studioにあります。
最後に、6番目の問題は、このメッセージが誤検知であることをツールにどれだけ便利に伝えることができるかです。 Visual Studioで使用される#pragma warning disableのメカニズムにより、分析が再開されたときにのみメッセージを非表示にできます。 PVS-Studioのメカニズムとは異なり、分析を再起動せずにメッセージを「False Alarm」としてマークし、非表示にすることができます。
これらの6つの問題はすべて、コード分析自体の品質には影響しませんが、非常に重要です。 結局のところ、ツールの使いやすさは、分析の品質を評価することになるかどうかに依存する不可欠な指標です。
合計で、次の図が表示されます。 eMuleプロジェクトは、PVS-Studioよりも数倍高速なVisual Studioに組み込まれた静的アナライザーによってチェックされます。 しかし、Visual Studioアナライザーを使用するのに3日かかりました（実際にはもっと少なくなりましたが、リラックスするには他のタスクに切り替える必要がありました）。 また、PVS-Studioを使用するのに4時間しかかかりませんでした。
ご注意 検出されたエラーの数に関して、両方のアナライザーはほぼ同じ結果を示し、このプロジェクトで同じエラーを検出しました。
おわりに
静的アナライザーを互いに比較することは、非常に困難で複雑なタスクです。 そして、どのツールがより優れているかという質問に答えることは不可能です。 特定のプロジェクトとユーザーに最適なツールについてのみ話すことができます。