静的コード分析に関する神話を破る

フォーラムで人々とコミュニケーションをとりながら、静的分析の方法論に関するいくつかの永続的な誤解に気付きました。 次の神話を払拭したい：

1. 静的アナライザーは1回限りの製品です。
2. プロの開発者は愚かな間違いを犯しません。
3. 動的分析は静的分析よりも優れています。
4. プログラマーは、静的アナライザーにルールを追加したいと考えています。

神話1-静的アナライザーは1回限りの製品です

フォーラムで議論するとき、このステートメントは次のようになります（集合イメージ）。



試用版/クラック版を使用すると、すべてのプロジェクトを無料で実行し、古いエラーを見つけて、実際にはしばらく落ち着くことができます。



誰もが幸せです。 人々はチェックしました。 アナライザーの開発者は、彼らがだまされて奪われたことを知りませんでした。



この場合、プログラマはツールの作成者ではなく、自分を欺いた。 彼は行われた仕事からの利益の外観のみを受け取りましたが、本当の利益は受け取りませんでした。 これまでのところ、私はこの考えを伝えることができませんでしたが、私はそれをやろうとし続けます。 静的アナライザーのシングルスタートからの使用はありません。



類推：



コンパイラの警告レベル/ W0を設定します。 そして、私たちはプロジェクトを開発しています。 私たちは誓い、愚かな間違いやタイプミスを修正し、より多くの時間をテストします。 その後、時折/ W3をオンにして警告付きで戦い、再び/ W0に戻ります。 同時に、コンパイラが/ W3レベルで提案できることは大胆にも、長い間デバッガで検索し、10〜100倍の時間を費やしました。 さらに、プログラマーは/ W3の結果が気に入らないことに注意してください。 結局のところ、彼はテストとデバッグによってほとんどすべてのエラーを修正しました。 レベル/ W3のコンパイラは、ほとんどが誤検知を生成します。



静的分析に戻ります。 写真は完全に同一です。 アナライザーのまれな起動により、多くの誤検知が発生します。 これらのエラーは他の方法で検出されるため、ごくわずかです。



/ W3スイッチと同様に、静的分析を使用することは、定期的に使用する場合に最も役立ちます。 ところで、静的分析は、コンパイラーによって発行される警告の一種です。 かつて古いアナライザーに実装されていた多くの診断は、徐々にコンパイラーに移行しています。 もちろん、診断計画では、アナライザーは常にコンパイラーよりも優先されます。 このために特別に設計されています。 コンパイラには他の懸念事項があり、さらに厳しいパフォーマンス要件が課されています。



議論の渦中にいる人の中には、このように反応する人もいます。



この考え方は、初心者の学生にも当てはまります。 専門家にとって、これはそれほど重要ではありません。 私は/ W0を入れれば、私は悪化しません。 松葉杖ツールの数を増やすのではなく、プログラミングスタイルを改善する必要があります。



上記のすべてに完全に同意します。 しかし、次のようにテキストを再生してやり直しましょう。



この考え方は、初心者ドライバーにも当てはまります。 専門家にとって、これはそれほど重要ではありません。 シートベルトを締めなければ、悪化することはありません。 運転スタイルを改善し、安全コンポーネントの数を増やす必要はありません。



繰り返しますが、議論することはできません。 ただし、適切に考えられたドライバーであれば、締めるのがまだ有用であることを理解しています。 静的解析も役立ちます。 実際、最も経験豊富なプログラマーでさえ、エラーやタイプミスの影響を受けません。 そして、 この記事で与えられた例は、 これの良い確認です。 もちろん、すべてのプロのプログラマは、そのような愚かな間違いを犯さないと確信していますが、それについては後で詳しく説明します。

第二の神話-プロの開発者は愚かな間違いを犯さない

2番目の神話：「プロの開発者は、主に静的コードアナライザーによってキャッチされる愚かな間違いを犯しません。」



フォーラムで議論するとき、このステートメントは次のようになります（集合イメージ）。



プロの開発者である私は、N年間、メモリの破損やオブジェクトの寿命などの問題を抱えていません。 静的分析はマクドナルドのツールであり、ここ（専門フォーラム）でオタクが座っています。 現在、私の主な問題は、オブジェクトの状態に関する暗黙のコントラクトを使用して、アルゴリズムと他の開発者との統合をテストするのが難しいことです。



タイプミスの問題と不注意のエラーのように聞こえますが、これは多くの学生です。 プロの開発者は長い間それらを作成しておらず、主な問題は同期の問題や複雑なデータ処理アルゴリズムなどの複雑なエラーが原因です。



そうではありません。 プログラマーは愚かな間違いを犯します。 あなたは私を聞いていないことを知っています。 私は異端の考えを繰り返します。 すべてのプログラマは愚かな間違いを犯します。 どんな種類の専門家であっても。 人々は間違いを犯しがちです。 ほとんどの場合、これらのエラーは単純です。



プログラマーは、エラーに関する私の声明について非常に不親切です。 彼らの意見では、非常に長い間そのような過ちを犯さなかったのは彼らでした。 精神の興味深い側面がここで機能し、興味のないプログラミングの瞬間の記憶を除外すると思います。



少し脱線して、なぜさまざまな星占いが粘り強いのかを思い出しましょう。 最初の理由は非常に曖昧な言葉遣いであり、人が自分に順応するのは簡単です。 しかし、2番目のコンポーネントに興味があります。 人々は、予測が実現しなかった場合を覚えていません。 しかし、彼らは自分たちの生活状況が星占いで説明された状況と一致した場合を非常によく思い出し、語り直します。 その結果、ホロスコープを話したり思い出したりすると、ホロスコープが機能していることを示すN個の確認が見つかり、ホロスコープが機能しなかったN * 10のケースについては覚えていません。



プログラマーがエラーを検索すると、似たようなことが起こります。 彼は複雑で興味深い間違いについてよく覚えています。 同僚と議論したり、ブログにメモを書いたりできます。 変数「AB」の代わりに「BA」を書いたことに気付くと、彼は単に間違いを訂正し、この事実はすぐに彼の記憶から消えます。 フロイトは、次の記憶の特徴に注意を向けました。自分についての肯定的な発言を記憶し、否定的な発言を忘れることは人間の本性です。 人がアルゴリズムの問​​題で難しいエラーと戦っている場合、それを修正すると、自分をヒーローと見なします。 覚えて、他の人に伝える価値さえあります。 彼が愚かなバグを見つけたとき、それを覚える理由と欲求はありません。



どのような証拠がありますか？ ほとんどのタイプミスや間違いは修正されていますが、それらのいくつかはまだ気づかれていません。 そして、 このようなエラーの多くの例がこの記事にあります。 この記事は、間違いは初心者ではなく、資格のあるプログラマーが犯したことを明確に示しています。



おわりに プログラマーは、思ったよりもタイプミスを修正するのに多くの時間を費やしています。 静的分析ツールは、テスト段階の前でもこれらのエラーの一部を特定することにより、開発者の労力を大幅に節約できます。

神話3-動的分析は静的よりも優れている

誤解3：「valgrind for C / C ++のようなツールを使用した動的検証は、静的コード分析よりもはるかに生産的です。」



ステートメントはかなり奇妙です。 動的および静的分析は、互いに補完する2つの異なる方法論にすぎません。 プログラマーはこれを理解しているようです。 しかし、動的分析は静的分析よりも優れていると何度も耳にします。



静的コード分析の長所をリストします。



すべてのプログラムブランチの診断

実際の動的分析では、プログラムのすべてのブランチをカバーすることはできません。 これらの言葉の後、valgrindファンは正しいテストを行う必要があると主張します。 理論的には、彼らは正しいです。 しかし、これを行おうとした人はだれでも、作業の複雑さと量を理解しています。 実際には、優れたテストでもプログラムコードの80％しかカバーしていません。



これは、非標準/緊急事態を処理するコードセクションで特に顕著です。 古いプロジェクトを使用すると、これらの場所の静的アナライザーによってほとんどのエラーが検出されます。 その理由は、プロジェクトが古い場合でも、これらのサイトは実際にはテストされていないためです。 私が意味することを示すために、非常に短い例を示します（FCE Ultraプロジェクト）：

  fp = fopen（name、 "wb"）;
 int x = 0;
 if（！fp）
   int x = 1; 

ファイルが開かれていない場合、「x」フラグは1と等しくなりません。 プログラムで何かがうまくいかないとき、それらが適切なエラーメッセージの代わりに落ちるか、無意味なメッセージを出すのは、まさにそのようなエラーのためです。



拡張性

動的な方法を使用して大規模なプロジェクトを定期的にチェックするには、特別なインフラストラクチャを作成する必要があります。 特別なテストが必要です。 異なる入力データを使用して、アプリケーションの複数のインスタンスを並行して実行する必要があります。



静的分析は数倍簡単にスケーリングできます。 原則として、静的解析を実行するプログラムに多数のコアを持つプログラムを提供するだけで十分です。



高レベル分析

動的アナライザーには、どの関数がどの引数で呼び出されるかを知っているという利点があります。 その結果、彼はコールの正確さを確認できます。 ほとんどの場合、静的分析ではこれを見つけ出し、引数の値を確認できません。 これはマイナスです。 ただし、静的分析は動的分析よりも高いレベルの分析を実行します。 そしてこれにより、彼は動的分析の観点から正しいものを探すことができます。 簡単な例（ReactOSプロジェクト）：

  void Mapdesc ::識別（REAL dest [MAXCOORDS] [MAXCOORDS]）
 {
   memset（dest、0、sizeof（dest））;
   for（int i = 0; i！= hcoords; i ++）
     dest [i] [i] = 1.0;
 } 

動的分析の観点から見ると、ここですべてが順調です。 しかし、静的解析ではアラームが鳴ります。これは、配列内の非常に多くのバイトがゼロにリセットされるのは非常に疑わしいためです。



または、Clangプロジェクトの別の例を次に示します。

  MapTy PerPtrTopDown;
 MapTy PerPtrBottomUp;
 void clearBottomUpPointers（）{
   PerPtrTopDown.clear（）;
 }
 void clearTopDownPointers（）{
   PerPtrTopDown.clear（）;
 } 

ここで動的アナライザーは何を疑うことができますか？ なし。 静的アナライザーは、何かが間違っていると疑う場合があります。 ここでのエラーは、clearBottomUpPointers（）の内部は「PerPtrBottomUp.clear（）;」である必要があるということです。

神話4-プログラマーは静的アナライザーにルールを追加したい

神話4：「静的アナライザーはカスタムルールを追加できるはずです。 プログラマーは独自のルールを追加したいのです。」



いいえ、彼らは望んでいません。 実際、彼らは特定の言語構造を見つけるといういくつかの問題を解決したいと考えています。 そして、これは診断ルールの作成と同じではありません。



私はいつも、自分のルールの実装はプログラマが望むものではないと答えました。 また、プログラマーの要求に応じてアナライザー開発者が診断を実装すること以外の代替手段はありませんでした（ このトピックに関する記事 ）。 最近、私はドミトリー・ペトゥニンと密接に話しました。 彼は、Intelソフトウェア検証ツールのコンパイラテストおよび開発の責任者です。 彼はこのトピックに対する私の理解を広げ、私が考えていたアイデアを表明しましたが、最終版では決して定式化しませんでした。



ドミトリーは、プログラマーが診断ルールを作成しないという私の信念を確認しました。 その理由は非常に単純です-それは非常に困難です。 多くの静的分析ツールには、ルールのセットを拡張する機能があります。 しかし、これはショーのために、またはツールの作成者の便宜のために行われました。 新しい診断を開発するために、トピックを深く掘り下げます。 経験のない愛好家がそれを取るなら、彼の規則からほとんど実用的な利益はありません。



これで問題の理解が終わりました。 豊富な経験を持つドミトリーはそれを拡大しました。 つまり、状況は次のようになります。



プログラマーは、コードのパターン/エラーを本当に探したいと思っています。 彼らは本当にそれを必要とします。 たとえば、人はintからfloatへのすべての明示的なキャストを見つける必要があります。 この問題は、grepなどのツールを使用して解決することはできません。 実際、「float（P-> FOO（））」という形式の構造では、FOO（）関数がどの型を返すかは不明です。 この時点で、プログラマーは、静的アナライザーで独自のチェックを追加することにより、そのような構造の検索を実装できるという結論に達します。



ここが重要なポイントです。 人間は、独自の分析ルールを作成する必要はありません。 彼は特定の問題を解決する必要があります。 彼が望んでいるのは、静的解析メカニズムの点で非常に小さなタスクです。 これは、車を使ってライターからタバコを点火するのと同じです。



そのため、私とDmitryは、アナライザーを操作するためのAPIをユーザーに提供するという考えをサポートしていません。 これは開発の面で非常に難しいタスクです。 そして同時に、人はそれの1％以上を使用する可能性は低いです。 不合理に。 開発者が拡張モジュール用の複雑なAPIを作成したり、ルールを記述するための特別な言語を作成したりするよりも、ユーザーの要望を実装する方が簡単で安価です。



読者は、「APIで開くと、機能の1％しか開かれず、誰もが満足するでしょう」と気付くでしょう。 はい、そうです。 しかし、強調がどのように変化したかを見てください。 ルールの開発から、実際にはgrepに似たツールですが、プログラムコードに関する追加情報があれば十分であるという結論に達しました。



そのようなツールはまだありません。 問題を解決したい場合は、私に書いていただければ、PVS-Studioアナライザーで実装を試みます。 たとえば、最近、明示的な型変換を見つけるためのいくつかの願いを実現しました： V2003 、 V2004 、 V2005 。 このような願いを実現することは、オープンなインターフェースを作成して維持するよりもはるかに簡単です。 これはユーザー自身にとって簡単です。



ちなみに、おそらくそのようなツールは、最終的にインテルC ++のフレームワークに登場するでしょう。 Dmitry Petuninは、コード構造と変数の種類に関する知識を備えたgrepのようなツールを作成する可能性について議論していると述べました。 しかし、これは抽象的な方法で議論されました。 本当に作成するかどうかはわかりません。