私が読んだ記事の多くは、この仮定に基づいています。 N行のコードのプロジェクトで2つのエラーが見つかった場合、N * 100行の本格的なプロジェクトでは、200のエラーしか見つけることができません。 そして、このことから、静的解析は確かに優れているが、優れたものではないと結論付けられました。 エラーが少なすぎます。 他の欠陥検索技術を開発することをお勧めします。
人々が小さなプロジェクトでアナライザーを試す主な理由は2つあります。 まず、大規模な作業ドラフトを検証するのはそれほど簡単ではありません。 何かを構成し、どこかに何かを書き、スキャンからいくつかのライブラリを除外するなどの必要があります。 当然、これをすべてやりたくありません。 設定を台無しにしないで、すぐに何かをチェックしたいという要望があります。 第二に、巨大なプロジェクトは膨大な数の診断メッセージを受け取ります。 そして再び、私はそれらを分析するのに多くの時間を費やしたくありません。 小規模なプロジェクトを受講する方がはるかに簡単です。
その結果、人は自分が取り組んでいる大規模なプロジェクトには触れず、小さなものを取ります。 たとえば、彼の古いコースプロジェクトでも、GitHubを使用した小さなオープンソースプロジェクトでもかまいません。
彼はこのプロジェクトをチェックし、大規模なプロジェクトで検出できるエラーの数を線形補間します。 そして、彼は研究に関する記事を書いています。
一見すると、そのような研究は正しく、有用に見えます。 しかし、そうではないと確信しました。
これらすべての研究の最初の欠点は明らかです。 彼らは、プロジェクトの動作するデバッグバージョンが取得されることを忘れています。 静的分析ですぐに発見できるエラーの多くは、ゆっくりと悲しい検索が行われました。 テスト中またはユーザーの苦情の後に検出されました。 つまり、静的解析は一定のツールであるが、単回使用ではないことを忘れています。 結局のところ、プログラマーは、年に1回ではなく、コンパイラーによって発行される警告を定期的に確認します。
研究の2番目の欠陥により、事態はより複雑で興味深いものになります。 小規模プロジェクトと大規模プロジェクトを等しく評価することは不可能であるという明確な感覚がありました。 学生に5行で、1000行のコードを含む期末レポートの良いプロジェクトを書いてもらいます。 500日後には、100,000行のコードを含む優れた商用アプリケーションを作成できなくなると確信しています。 それは複雑さの成長を妨げます。 プログラムが大きくなると、プログラムに新しい機能を追加することが難しくなり、テストするのに必要なエラーが増えます。
一般的に、感覚はありましたが、私はそれをどうにか定式化することができませんでした。 突然、従業員の一人が私の助けに来ました。 Steve McConnellの本The Perfect Codeを研究していると、彼はその中に興味深いタブレットを見つけました。 そして、私は彼女を忘れました。 このタブレットはすぐにすべてをその場所に置きます！
もちろん、小さなプロジェクトを考えると、大きなプロジェクトのエラーの数を見積もることは正しくありません！ エラーの密度は異なります！
プロジェクトが大きいほど、含まれるコードの1000行あたりのエラーが多くなります。 この素晴らしいテーブルをご覧ください。
表1.プロジェクトのサイズと典型的なエラー密度。 この本は、データソースを示しています。「プログラムの品質とプログラマの生産性」（Jones、1977）、「ソフトウェアコストの見積もり」（Jones、1998）。
データを認識しやすくするために、グラフを作成します。
チャート1.プロジェクトの典型的なエラー密度。 青は最大量です。 赤は平均額です。 緑が一番少ない。
これらのグラフを考慮すると、依存性が線形ではないことが明らかになると思います。 プロジェクトが大きいほど、ミスを犯しやすくなります。
もちろん、すべてのエラーが静的アナライザーによって検出されるわけではありません。 ただし、プロジェクトが大きいほど効果的です。 定期的に使用するとさらに効果的です。
ちなみに、小規模なプロジェクトでは、エラーがまったく見つからない場合があります。 または、それらの数個のみがあります。 この場合、完全に間違った結論に達する可能性があります。 したがって、実際の作業プロジェクトでエラーを見つけるためのさまざまなツールを試すことを強くお勧めします。
はい、それはより難しいですが、可能性について正しい考えを得るでしょう。 たとえば、 PVS-Studioの作成者の1人として、私たちに連絡するすべての人を支援することを約束できます。 PVS-Studioの学習中に何かが失敗した場合は、ご連絡ください。 多くの場合、ツールを適切に調整することで多くの問題を解決できます。
PS
Twitter @Code_AnalysisまたはRedditサイトのコミュニティに参加することをお勧めします。 それらの中で、C / C ++、静的コード分析、最適化、およびプログラミングに関するその他の興味深いトピックに関する興味深い記事へのリンクを定期的に公開しています。 私たちと他の両方の記事。 そして、「私はPRです」を除いて、どこにでも追い出されました。