静的コード分析の本当の利点は何ですか？
pc-lint または [〜＃〜] qac [〜＃〜] などのツールを使用して、コードベースで静的コード分析を実行できます。
私の経験では、静的分析は非常に多くのノイズを発生させます。つまり、実際のバグではないが、何らかの理由で特定のルールセットのルールの1つに違反しているものに対する警告です。特定のルールを無効にすることは（ルールセットで有効にするため、またはコード内の特別なコメントによって）、非常に面倒なプロセスになる可能性があります。
静的コード分析の本当の利点は何ですか？
私はCoverity Preventと呼ばれる商用の静的コード分析システムを使用する場所で働いていましたが、それはすごいことでした！それは本当に洗練され、インテリジェントです。
私たちはそこに約18 GBのオープンソースコードとプロプライエタリCおよびC++コードの両方を投入しました。コードパスをたどると、人が追跡するのに永遠にかかるような微妙なバグがすぐに見つかります。また、通常はハイゼンバグであるものを特定するのにも優れていました。
コードベースに対して数日おきに実行され、「これは実際にはバグではありません」と伝えることができる素晴らしい機能であり、将来的にはそれを思い出すでしょう。
落とし穴は、コベリティは本当に高価です。彼らはコストを公表していませんが、商業プロジェクトの場合、年間数十万ドルから始まっていると私は理解しています。しかし、おそらくそれは私たちがたくさんの開発者とQAスタッフを雇わなければならなかったので、全体的に私たちの経営陣はそれが良い買い物であると考えているようでした。
その経験があるので、私は静的コード分析を非常に好意的に見ています。
新しい言語で始めるとき、コーチがいるのはいいことです。それが私が静的分析ツールについて考える方法です。私はたくさんのJavaScriptを書き、最初はいくつかの悪い習慣を身につけました。 Javascriptは非常に柔軟なので、ほとんど何でも手に入れることができますが、特定のパターンについてjslintから警告があった場合、後で内容を再学習する必要がなく、最初からより優れたコーディングパターンを選択できたでしょう。
スタティックアナライザーは、基本的には機械支援のコードレビューです。彼らは定期的なテスト中に見逃されるかもしれない疑わしい領域を指摘します。
たとえば、著者は本当にこの条件付きで課題を作成するつもりでしたか？
if (x = 1) {
...
}
あるいは、新人が字句鋳造を混乱させるかもしれません：
char* number = "123";
int converted = number;
確かに静的アナライザーは微調整が必要です。また、リビジョンコントロール、wiki、バグトラッカー、プリティプリンター、その他のツールも、いくつかの設定が必要です。プロジェクトが大きければ大きいほど、初期労働に対する報酬は高くなります。
コンサルタントの観点から見ると、すべての静的分析ツールにはノイズが含まれていますが、すべての静的アナライザーが同等に作成されているわけではありません。 Coverity、Klocwork、Grammatechなどの静的分析ツールには、より正確な結果を生成する優れた分析手法があります。さらに調整して微調整すると、通常はより良い結果が得られます（結局のところ、静的アナライザーは、小さな医療機器からネットワークオペレーティングシステムまで、あらゆる種類のコードで実行できる必要があります）。 「ノイズ」の定義は、修正に値するレポートを構成するための基準にも依存します。スペクトルの一方の端では、一部の開発者は修正しないすべてのレポートを「false」としてマークし（修正する時間がない不十分なコードでも）、もう一方の端では、いくつかのmil-aero誤検出さえも「修正」されていることを確認した医療機器会社は、コードがツールを混乱させるものである場合は、おそらく保守性を高めるため、より明確に記述する必要があります。
これらのツールの中には、より中心的な分析に重点を置いたものと、デスクトップに重点を置いたものがあります。 @ボブが述べたように、彼らはお金がかかります。
前の会社では、Parasoftのスタティックアナライザーを使用しました。また、ランタイムバグの少なくとも60％がコンパイル前に検出されたとチーム内では信じられていました。
ソフトウェアコードで手動レビューを実行することにより、ツールなしで静的解析を実行することもできます。これは多くの場合、コードの品質を改善するための最も費用対効果の高い方法です。
2番目に最適なオプションは、1つ以上のハイエンドの静的分析ツール（前述のCoverity、またはKLOCworkなど）に投資することです。たとえば、これらのツールはlintよりもはるかに深い分析を実行するため、信号対雑音比ははるかに優れています。
ノイズレベルが高いため、3番目のオプションとしてlintの使用を検討します。既存のプロジェクトにlintを適用することは、困難な作業になる可能性があります。
一般に、静的プログラム分析はここ数年で大きく進歩しています。現在の静的分析ツールは、深い手続き間分析を実行することができ、たとえば手順の前後の条件などを自動的に識別できます。これは、後のコードレビューにも役立ちます。
誤検出率が高いため、コンパイルごとに静的分析ツール（lintやFindBugsなど）を使用しないでください。
むしろ、相談するのは良い正気チェックですバグがあり、それを理解できない場合。その場合、誤検知を楽しませることができ、エラーの考えられる原因をすでに絞り込んでいる可能性があります。たとえば、モジュールを実行せずにバグを再現する場合は、FindBugsがモジュールに対して言っていることを無視できます。これは、コードの一部を見ているときに特に役立ち、thinkコンパイラはそれを文字通りに読み取りますが（Java equalsの代わりにクラスの型を取り込むObjectメソッドがある場合。
また、静的分析ツールを開発プロセスの一部にすることもできます。開発者がコードレビューを受け取ったら、FindBugsも実行する必要があります。つまり、それは便利ですが、コンパイラやテキストエディタほど頻繁には使用しません。