ソース コードで静的コード分析を行う利点は何ですか? 私は FxCop をいじっていましたが、コーディング標準に従っていることを確認する以外に何か利点があるかどうか疑問に思っていました。
10 に答える
あらゆる種類の利点があります。
- コードにアンチパターンがある場合は、警告を受けることができます。
- ソース コードについて有用なことを示す特定の指標 (McCabe の Cyclomatic Complexity など) があります。
- また、静的解析からコール グラフやクラス ダイアグラムなどの優れたものを取得することもできます。新しいコード ベースを攻撃している場合、これらは素晴らしいものです。
ソースモニターを見てください
多くの種類のメモリ リークや一般的な論理エラーも、静的に捕捉できます。また、言及した「コーディング標準」の一部である可能性がある循環的複雑度などを見ることもできますが、コードのアルゴリズムの「クリーンさ」を評価するために使用する別のメトリックである可能性があります。
いずれにせよ、プロファイリング (動的または実行時分析) と静的分析/lint を適切に組み合わせることによってのみ、一貫した信頼性の高いコード ベースが保証されます。ああ、それとちょっとした運 ;-)
それはトレードオフです。フレームワークとガイドラインの理解を深めたいと考えている個々の開発者には、ぜひお勧めします。FxCop は多くのノイズや誤検知を生成しますが、次の利点も発見しました。
バグを検出します (たとえば、未使用の引数に関する警告は、メソッド本体で間違った引数を使用したことを示している可能性があります)。
FxCop が従っているガイドラインを理解することは、より優れた開発者になるのに役立ちます。
ただし、能力が混在するチームでは、FxCop があまりにも多くの誤検知を生成して役に立たない可能性があります。ジュニア開発者は、FxCop によって投げ出された難解な違反のいくつかが彼らに関係するべきなのか、それとも単なるノイズなのかを理解するのに苦労するでしょう。
結論:
社内フレームワークなどの再利用可能なクラス ライブラリを開発している場合は、優れた開発者がいて、FxCop を使用していることを確認してください。
能力が混在するチームによる日常のアプリケーション開発では、おそらく実用的ではありません。
利点は、ソフトウェアアプリケーション内の技術的負債を自動的に見つけて定量化できることです。
静的コード分析ツールは、多くの開発者やテスターがアプリケーションの存続期間を行き来する大企業のアプリケーション開発に不可欠であると思いますが、コードの品質を高く維持し、技術的負債を適切に管理する必要があります。
FxCop
FxCopにすべての警告のリストがあります。次の領域から警告があることがわかります。
設計上の警告
.NET Framework 設計ガイドラインで指定されている適切なライブラリ設計をサポートする警告。
グローバリゼーションに関する警告
世界対応のライブラリとアプリケーションをサポートする警告。
相互運用性に関する警告
COM クライアントとの対話をサポートする警告。
命名に関する警告
.NET Framework 設計ガイドラインの命名規則への準拠をサポートする警告。
パフォーマンスに関する警告
高パフォーマンスのライブラリとアプリケーションをサポートする警告。
セキュリティ警告
より安全なライブラリとアプリケーションをサポートする警告。
アプリケーションによっては、これらの領域のいくつかはあまり興味深いものではないかもしれませんが、たとえば COM の相互運用性が必要な場合、テストは落とし穴を回避するのに非常に役立ちます。
その他のツール
他の静的チェック ツールは、 IDisposable を破棄しない、メモリ リーク、その他の微妙なバグなどのバグを検出するのに役立ちます。極端な場合は、まだリリースされていないNStaticツールを参照してください。
NStatic は、冗長パラメーター、定数に評価される式、無限ループ、およびその他の多くのメトリックなどを追跡するために使用されます。
ソース コードで静的コード分析を行う利点は何ですか?
利点は、実行される静的コード分析の種類によって異なります。静的コード分析は、単純なものから高度な手法までさまざまです。たとえば、ソース コードに関するメトリックを生成して、エラーが発生しやすいコードを特定することは、1 つの手法です。他の手法では、コード内のバグを積極的に見つけようとします。洗練された手法では、正式な方法を使用して、コードにバグがないことを証明します。
したがって、その利点は、使用されている静的コード分析の種類によって異なります。この手法がメトリック (コードの複雑さなど) を生成する場合、コード レビュー中にこれらのメトリックを使用して、エラーが発生しやすいコードを特定できるという利点があります。この手法でバグが検出された場合、開発者が単体テストの前にバグを特定できるという利点があります。コードにバグが含まれていないことを証明するために正式な方法に基づく手法が使用されている場合、この情報を使用して、コードに特定の種類のバグがないことを QA 部門 (または認証機関) に証明できるという利点があります。
手法と利点の詳細な説明は、次のページにも記載されています: www.mathworks.com/static-analysis
実際には、fxcop は、コーディング標準に従うのに特に役立ちません。それが役立つのは、よく考えられたフレームワーク/API を設計することです。コーディング標準の一部 (パブリック メンバーのケーシングなど) が FxCop によってキャッチされることは事実ですが、コーディング標準は焦点ではありません。
コーディング標準は、 fxcopのように MSIL の代わりにソース コードをチェックするstylecopでチェックできます。
Dispose IDisposables を忘れるなど、実際のバグをキャッチできます。
ルールによって異なりますが、多くの微妙な欠陥を回避したり、コードをクリーンアップしたり、潜在的なパフォーマンスの問題を検出したりできます。
言い方を変えると、それが安くて無料で (時間と金銭的コストの両方で)、何も壊れないのであれば、なぜそれを使用しないのでしょうか?