静的コード分析に関する議論

静的コード分析に関する非常に多くの偏見を集めた私の記事の1つにコメントがあり、その答えを別の出版物に掲載することにしました。 この回答により、コメント作成者と疑わしいすべてのプログラマーが、静的分析ツール全般、特にPVS-Studioを再確認できるようになることを願っています。

コメント

コメントは、「 Yandexの開発者に挨拶します」という記事に書かれています。 最初はここです。 引用します：

これらのすべてのアナライザーは、利益を除いて、ビルド、誤検知、情報ノイズ、および誤った安心感を遅らせるという形で出血を追加します。 私にとっては、専門家にとってそのようなツールは少ないほど良いと判断しました-出血は簡単に利益を上回ります。 しかし、これはNubasisをあまり助けません-彼らはユニットテストを書くことを学び、警告を差し込む時間を無駄にしません。 おそらく、Yandexは同じように考えています。 リリース前にテストを行うと、出血が少なくなり、通常の時間/エラー率を追跡できるようになりますので、xs。 免責事項：PVS-Studio私は試していません。

そして追加があります：

真の競合他社（事実上ではなく、事実上の）を忘れないでください：動的アナライザー（ASAN、MSAN、TSAN、UBSAN）。 もちろん、彼らには問題があります。彼らはそれほど速く動作せず、より多くのリソースを必要とします。 しかし、これらには利点もあります。ファジング中にSANが既に「このような」何かを見つけた場合、反撃は役に立たない-これは間違いです。修正する必要があります。 そして、静的アナライザーでは...何でも起こり得ます。 したがって、clang / gcc / msvc（無料で常に利用可能）に組み込まれたアナライザーと* SAN'om（困難で高価ですが誤検知-ほぼゼロ、エラーはすぐにバグトラッカーに入力できます）の間のニッチに入る必要があります。 このニッチはとても大きいですか？

私の意見では、これらは非常に良いコメントであり、静的コード分析に関する誤解の集合的なイメージとして使用できます。 それぞれの重要な発言を注意深く調べてみましょう。



PVS-Studio静的アナライザーのエバンジェリストの立場から話をしますが、私が言うことはすべて、静的解析ツール全般に関連するものです。

アナライザーは主に注意散漫なノイズを生成します

これらのすべてのアナライザーは、利益を除いて、ビルド、誤検知、情報ノイズ、および誤った安心感を遅らせるという形で出血を追加します。 私にとっては、専門家にとってそのようなツールは少ないほど良いと判断しました-出血は簡単に利益を上回ります。



静的アナライザーは、コンパイラに実装されている警告メカニズムの高レベルでインテリジェントなバージョンです。 実際、静的アナライザーに実装されている一部の診断は、コンパイラーに徐々に現れます。 ブーストライブラリからstdライブラリに何かが入るようなものです。 同時に、ブーストライブラリは存続し、利点をもたらします。 類推は最良ではないかもしれませんが、その考えは明確だと思います。



そのため、アナライザーはコンパイラーよりもコードを定性的かつ詳細に検査します。 さらに、優れたアナライザーの誤検知の割合は、コンパイラーの場合よりもはるかに少ないです。 さらに、静的分析ツールは、使用を簡素化する多くの追加機能を提供します。 このために、アナライザーの開発者はお金を受け取ります。



私は次のタイプの異議を予見します：「あなたが装飾する誤検知の割合について。 コンパイラはほとんど警告を生成しません。静的アナライザーを実行すると、何千もの警告が表示されます。



すべてが非常に簡単です。実際、アナライザーは調整されていません。 比較は不公平です。 まだコンパイラで使用されていない別のコードでコードをコンパイルしてみてください。同じ警告が表示されます。数万、または数万の警告が表示されます。 そして、これは一般に、完了せずにコードをコンパイルするためにすぐに判明することが提供されています。



前述したように、優れた静的コードアナライザーは誤検知をほとんど発生させず、誤検知を簡単に抑制できます。 設定に少し時間をかけるだけです。 これらの考えは、私の記事「 EFLコアライブラリの例を使用したPVS-Studioアナライザーの特性、誤検知の10〜15％ 」で詳しく説明されています。



私は主なアイデアから少し離れましたが、静的アナライザーはコンパイラーで警告を生成するメカニズムよりも強力なツールであることを説明しなければなりませんでした。



そのため、静的解析の放棄は、すべてのコンパイラ警告をオフにするのと同じくらい愚かなことです。 見て、元のコメントを少し書き換えましょう：



コンパイラーによって発行されるこれらのすべての警告は、有用性に加えて、ビルドの遅延、誤検知、情報ノイズ、および誤った安心感という形で出血を追加します。 私にとっては、専門家にとってそのようなツールは少ないほど良いと判断しました-出血は簡単に利益を上回ります。



適切なプログラマであれば、ナンセンスが書かれていると言うでしょう。 はい、コンパイラの警告は時々ノイズです。 しかし、これは彼らの利益を否定するものではありません。



コンパイラの警告が誤った安心感を与えると誰かが言った場合、これは発言者の問題であり、コンパイラの問題ではありません。



最後に、警告による害が利益を上回るという事実は、プロフェッショナリズムをまったく与えませんが、逆に、そのようなプログラマーのプロとしての不適格性を与えます。 コンパイラの警告の使用方法を知らないだけです。



ご想像のとおり、静的コード分析にも同じことが当てはまります。 誤解の最初の部分を詳細に検討し、次へと進みます。

初心者には静的分析は使用できません

しかし、これはNubasisをあまり助けません-彼らはユニットテストを書くことを学び、警告を差し込む時間を無駄にしません。



何よりもまず、初心者はプログラミング言語、コードのデバッグ方法、単体テストの書き方などを学ぶ必要があることに同意します。 基本的な知識がなければ、支援ツールは役に立ちません。



はい、おそらく、静的分析は、そもそも注意を払うべき技術ではありません。 ただし、静的分析は、開発者のプロ意識に関係なく、常に友人です。 生徒にとっては、コードに何か問題があることを伝え、さらなる言語学習のための食物を提供するのに役立つかもしれません。 ところで、学生のコードをチェックすることについての興味深い記事があります：「 魔術師の学生によって偶然に呼ばれた悪について」 。



新入社員についてではなく、たとえば新入社員について話している場合、静的分析により、チームリーダーはプログラマが何であり、何を学ぶべきかをすばやく理解できます。



ご注意 ところで、単体テストも万能薬ではありません。静的アナライザーはこの方法論を補完するものであり、競合しません。 記事「 静的分析がTDDを補完する方法 」を参照してください。

リリース前に静的アナライザーを実行できます

リリース前にテストを行うと、出血が少なくなり、通常の時間/エラー率を追跡できるようになりますので、xs。



これは、アナライザーを使用するまったく間違った方法です！ 最悪のシナリオは、静的分析がまったく使用されないか、5年ごとに使用される場合です。



このアプローチでは、ユニットテスト、デバッグ、テスターなどを使用して、すべてのエラーがゆっくりと悲しく検索されます。 そして、アナライザーの助けを借りてリリースをチェックする段階で、大部分は軽微なエラーが見つかりますが、それらは重要でないために以前には発見されませんでした。



静的分析のポイントは、できるだけ早くエラーを検出することです！ つまり、コードを書く段階です。 これは、静的アナライザーが最も時間、神経、お金を節約する方法です。



ここでも、コンパイラの警告との類推が適切です。 警告が完全に無効になり、プロジェクトが3か月間開発されたとします。 そして、リリースの前日、これらすべてのコンパイラ警告がオンになります。 同意します、これはある種の愚かさです。



また、ここでは、ワンタイムアナライザーの愚かさに関する専門家の記事に精通することを提案することも適切です。「 静的コード分析の哲学：100人のプログラマーがいます。アナライザーはエラーをほとんど見つけませんでした。 それは役に立ちませんか？ 」

動的分析-静的分析の競合

真の 競合他社（事実上ではなく、事実上の）を 忘れないでください ：動的アナライザー（ASAN、MSAN、TSAN、UBSAN）。 もちろん、彼らには問題があります。彼らはそれほど速く動作せず、より多くのリソースを必要とします。 しかし、これらには利点もあります。ファジング中にSANが既に「このような」何かを見つけた場合、反撃は役に立たない-これは間違いです。修正する必要があります。 そして、静的アナライザーでは...何でも起こり得ます。



はい、動的アナライザーには利点がありますが、欠点もあります。 動的アナライザーは、静的アナライザーが気付かないエラーを見つけることができます。 そしてその逆！ 動的アナライザーには、ほとんど誤検出がありません。 しかし、プログラムの一部をテストするのは非常に難しいか、時間がかかりすぎます。 それどころか、静的アナライザーはソースコード全体を非常に迅速にチェックします。



「静的分析対動的分析」の精神で、これらの方法論を考慮しないことが重要です。 これらのテクノロジーは競合しませんが、互いに補完します。 静的分析と動的分析を組み合わせて使用​​すると、膨大な数のさまざまなエラーを特定できます。



プロのプログラマーは「何を選ぶべきか？」という質問を投げかけないため、ダイナミックアナライザーを競合他社とは見なしません。 彼らはこれらのテクノロジーの両方を使用します。なぜなら、どちらも「コードの品質を改善するために他に何ができるでしょうか？」という質問に答えるのに役立つからです。



ご注意



ちなみに、私が理解できない何らかの理由で、一部のプログラマーは、動的アナライザーが静的アナライザーと同じことを行うことができると信じています。 いいえ、これはそうではありません;動的アナライザーは多くを行うことができません。 このテーマに関する2つの優れた出版物があります。

• 静的および動的コード分析 。
• 静的アナライザーを使用して、動的アナライザーValgrindのコードをチェックします 。

コンパイラと動的アナライザーの間のニッチに侵入することは困難です

したがって、clang / gcc / msvc（無料で常に利用可能）に組み込まれたアナライザーと* SAN'om（困難で高価ですが誤検知-ほぼゼロ、エラーはすぐにバグトラッカーに入力できます）の間のニッチに入る必要があります。 このニッチはとても大きいですか？



ニッチは広く、PVS-Studioアナライザーだけでなく、SonarSource、Synopsys（以前のCoverity）、Gimpel Software、Rogue Wave Softwareなど、他の多くの企業のツールにも適合しています。



ニッチが広いのはなぜですか？ 答えは簡単です。コメントの声は静的コードアナライザーを制限しません。 1つの境界で動的アナライザーを設定します。 しかし、以前に判明したように、競争はありませんが、友好的な共生があります。



もう一方の端はコンパイラです。 はい、コンパイラはよりスマートになっています。 ただし、静的解析ツールも静止しておらず、急速に開発されています。



懐疑論者のために、私はPVS-Studioがこれらのコンパイラのエラーを簡単に見つけることを示す多くの出版物を持っています。

• 検証LLVM（Clang） （2011年8月）、 2回目の検査 （2012年8月）、 3回目の検査 （2016年10月）
• GCCレビュー （2016年8月）
• Visual C ++コードは閉じられています。 ただし、ライブラリを確認し、PVS-Studioの機能を実証することはできます。 Visual C ++ライブラリ検証 （2012年9月）、 2番目の検証 （2014年10月）、 3番目の検証 （2017年5月）

PVS-Studio試したことがない

無駄に、:)を試してください。 多くの人々がそれを好み、彼らは私たちの顧客になります 。



さらに、PVS-Studioを試すのは非常に簡単です。 製品ページに移動して 、デモ版をダウンロードします。



ご不明な点がございましたら、サポートにお気軽にお問い合わせください。 大規模プロジェクトの分析、警告への対処、およびライセンスオプションに関するアドバイスを提供できます。



ご清聴ありがとうございました。コードレスコードをお祈りします。