この記事は機械翻訳されたものです。

Cutting Edge

コードの静的分析、コード コントラクト

Dino Esposito

多くは、それがあったが、時間の場合、アプリケーションのソースコード全体を印刷できませんでした信じられません.、上から下、バグや可能性のある misbehavior をキャッチするには 最近のソフトウェアの複雑さこの方法人間が乏しい-静的解析ツールなどのスマート ソフトウェアの一部ではなく。

コードの命令の動作の推論の静解析ソフトウェアで構成されます。 徐々 に、正解または不正解ステートメントと、出力を証明するために使用する知識ベースを構築することにより、ソース コードの調査、静的分析ツールを実施します。 静解析コードを実際に実行されません。 行を読み取るし、もの figures するだけです。 どのようなことでしょうか。

一般に、静解析はコード内の可能性があるバグを特定できるだけでなく期待と特定のコード セグメントにどの程度一致することを示します。

いくつかの時間に報告されている-少なくとも、優れた振り返ると作業アラン ・ チューリングによって 1930 年代-エラーが発生せず、特定のプログラムを終了するかどうかを決定する自動完全に信頼性の高い方法はありません。 どのような場合は、コンピューター サイエンスは概算では、ほとんど基づいているあり、バグを回避いくつかの行の場合があることを警戒している貴重なヘルプ。 現在のヘルプには、最新のプロジェクトのサイズを拡大または縮小し、真の価値を参照してください。 静的解析ツール可能性があります、絶対 certainties ことはできませんが、クラスを作成するときに、リアルタイムで動作して、それからについてどのような実装では、正しくない可能性がありますをすぐに提供されています。

静的な分析とテスト

テストおよび静的の基本的な違いが分析します。 開発者、テストを積極的に作成しますが、静解析を受動的に受けています。 テストの重要な条件は、実際には含まれないまたは重要な値をチェックしない場合は、結果は有効なできません。 (このツールを理解できるようには、静解析用ツールの事実についての警告により、違反、構成されている内部ルールの一部。 一般的には、ほぼ警告なしの静解析から取得は、ソフトウェアの品質のことがわかりますです。 その一方で、警告を取得自動的にソフトウェア buggy あり最初の実行時に失敗するとは限りません。 静解析の場合、アプリケーションがクラッシュする可能性のあるエラーをキャッチするには、上にある場合を検出します。 テストのように、静解析は非常に早く、開発段階では、プロジェクト全体にソフトウェア ・ エラーの影響が少なくての欠陥を検出できます。

型の静的なアナライザー

静解析では、多くのファセットおよびさまざまな実装のさまざまなレベルがあります。 静的分析の非常に基本的な種類の言語のコンパイラです。 コンパイラはソース コードを移動し、言語の構文規則と一致します。 これは、分析の最初のステップです。 ただし、最新のコンパイラが操作を行います。

コード コントラクトを派生クラスで合計すると、最新の C# コンパイラなど、リスコフの原則の違反を検出します。 このコンパイラは多くの場合、個の未使用の変数を参照できます。 ただし、どのようなコンパイラを検出し、警告として分類は必ずしもバグとして修飾しません。 それでも、コンパイラを実行する必要がある、明確なステップです。 プロジェクトとは、環境によっては、しばらくお待ちします。

FxCop より良いまだ、Visual Studio 2010年では、コード分析機能などのツールより詳細な分析コードの実行し、オン ・ デマンドで、またはビルドのたびに実行するように構成できます図 1 が表示されます。

図 1 Visual Studio 2010年プロジェクトでコード分析の設定

さらに、コードを処理するときに使用するルールを宣言によって設定することができます。 図 2 、大量の警告が表示されるすべてのルールは Visual Studio 2010年のコード分析を有効にするとリストの例を示しています。 これらの警告のいくつかの非常に特殊で、非常に容易より adherent と、マイクロソフトにコードを作成であることに注意してください。NET Framework のガイドライン。

(クリックすると拡大表示)

図 2 警告が受信するすべてのルールを有効にすると

静的な分析に関する重要なポイントは、自動ツール本当に正直なところ、厳密にはルールの違反でをに基づいて警告を与えることです。 検出されたルール違反は、必ずしもバグではありません。 違反のバグの場合は、おそらくエッジの場合、マーフィーの法則に完全に従って表示されます-だけが、最も被害します。

コンパイラや FxCop のような機能のオン ・ デマンド ・ ツールだけでなく別のカテゴリのツールは、多くのフィードバックが提供できるなどが、非同期的に動作します。 このカテゴリには、コード分析が、動的には入力として同じ種類の便利なヒントを提供する ReSharper 属しています。 クリックまたは 2 つのコードの編集をまた提供します。 ReSharper、たとえば、代入なしの変数、制御が渡らないコード、可能性のある null 参照およびさまざまな LINQ 式で変更されたが終了したときに、コンス トラクターとアクセスの仮想呼び出しなど、コードのにおいを検出します。 さらに、ReSharper コードのにおいは、独自の形式化し自動的に検索して入力しながらインテリジェントに置換することができます。 詳細および ReSharper の構造的な検索と置換の詳細な手順を示した例についてでブログの投稿を読む bit.ly/eCMvCL。

最後に、静解析では。NET Framework の 4 と Visual Studio 2010年コード コントラクトのチームによって作成される、静的チェッカー ツールを使用しても行います。

静的なチェックの動作

コード コントラクトと共に、Microsoft 静的チェッカー ツールは、コードをさらにコンパイルを調べて、コードできないことを確認しただけで不可能な権利を証明するまたは間違った契約をハイライトを提供します。 Visual Studio 2010年プレミアムまたは究極の Visual Studio チーム システム 2008年しかない場合は、静的チェッカーを取得できます。 これらのバージョンの要件をコード分析機能の要件に合わせている-は、これらの機能の Visual Studio Professional または Express エディションで利用可能です。

中間言語リライターのように、静的チェッカー Visual Studio 2010年の強化は個別のダウンロードです。 最新のコード コントラクトのビットを取得できます bit.ly/fF3wzl。 示すように明示的に静的なチェック、プロジェクト構成ごとを有効にする必要するでしょう図 3。

図 3 に静的なチェックのコードを有効にすると契約の Visual Studio 2010年

静的チェッカーはバック グラウンドで必要な場合は、実行できるし、明示的に各警告の波線を表示できます。 バック グラウンドの実行は、静的チェッカーは、ビルドのようなコードが変更されると、コンパイラで並列実行をスケジュールすることを意味します。

静的明示的なコントラクトと同様の暗黙的な検索の機能を持つことができます。 明示的なコントラクトは、前提条件、事後条件や不変式などのクラスのメソッドを宣言するいかなる契約です。 さらに、静的チェッカーも、組み込みのコード コントラクトを考慮および配列のインデックスは、常に保つかどうか配列の範囲内で、ゼロによる除算が行われますかどうかは null 参照を使用するかどうか、またはチェックインできます。 暗黙のコード コントラクトを表示チェック ボックスをオンを制御図 3。 暗黙の型コード契約を有効にすると、[出力] ウィンドウでのメッセージおよび警告が氾濫可能性がありますに注意してください。 これを行う、常に可能性がありますしないと開始後はいない可能性があります。 暗黙の型の配列境界義務契約があるときに、潜在的なエラーをキャッチするコード例を次に示します。

var numbers = new int[2];
numbers[3] = 0;

静的なチェックの機能のほとんどは、結果、前提条件と事後条件」などの明示的なコントラクトを使用します。

明示的なコントラクト

メソッドのいずれかで、次のコードがあるとします。

var orderId = GetLatestOrderId(); 
ProcessOrder(orderId);

変数は関数の呼び出しで取得したし、さらに処理するには、別の方法渡さ。 正解または不正解いくつか明示的なコントラクト情報を使用しないで、これらのステートメントを証明しようとするより、静的なチェックを実行できます。 有意義な事後条件、次のコードのように、GetLatestOrderId メソッドを公開する場合はその一方で、チェッカーは、連続した呼び出しが正しいかどうかを証明するためにできる場合があります。

public int GetLatestOrderId()
{
  Contract.Ensures(Contract.Result<int>() >0);
  ...
return n;
}

GetLatestOrderId メソッドは、値 0 を超える返品する明示的に宣言します。 チェックは合格になりますように、情報を取得し、そのナレッジ ベースに追加します。 GetLatestOrderId メソッドからの戻り値は、明示的な前提条件を別の方法への入力として使用されていることを検出すると、後で、チェッカーは、適切な操作が宣言されたコントラクトと一致しているを参照してくださいしようとします。 次の前提条件コントラクトについて考えてみましょう。

public void ProcessOrder(int orderId)
{
  Contract.Requires<ArgumentException>(orderId >0);
  ...
}

これら 2 つの明示的な契約契約を証明するために、チェックするための十分な情報を提供します。 この例では、余分な警告を表示されません。 しかし、もしこれらの契約のないでしょうか。 出力と同様に、「静的チェッカーを返します図 4. チェッカーが検出した、たとえば、メソッドが、契約する必要があり、何かは、返された出力については示されませんが、もう 1 つからデータを受信します。

図 4 実証されていない契約

静的チェッカーが最も外を取得するには、コード全体を通じてすべてコード コントラクトを使用する必要がありますが、クリアではずです。 さらに明示的なコントラクトより信頼性の高い、静的チェッカーことがあります。

仮定してアサート

ただし、場合によっては、新しいコードは、他のユーザーが作成した、更新できないレガシ コードと統合する必要があります。 レガシ コードは任意の契約があるない場合は、静的チェッカーからの警告が何度も取得しようとしています。 コード コントラクトの API、回避策を提供しています。

基本的には、情報を契約の実績のない警告を発信-チェッカーは、必要な情報を見つけることではありません。 ただし、開発者は、詳細について提供できます： 具体的には、前提条件。 ある図 5。

図 5 、静的チェッカーからの警告

可能性のある null 参照に関する警告が表示されます。 ヒントを参照してください。 明らかに、変数コンテキスト割り当てられても使用されています。 ツールヒントの実際の原因は誰か チェッカーは、か、別のものですか。

この例では、ツールヒント可能性のある null 参照、分析エンジンと誤って判断する ReSharper から、付属しています。 なぜ、チェックから類似のメッセージを取得しないでしょうか。 最初の行にある図 5。

Contract.Assume(context != null);

この命令では、チェックするを保証は、変数コンテキストは常に null です。 チェッカーはだけを信頼し、その情報の一部をナレッジ ベースに追加します。 ReSharper は現在を完全にサポートを提供しません。NET コードはなぜそれが警告により説明コントラクトをします。 一方、ReSharper は、一連の注釈と同じように前提データを使用することは。 参照してください bit.ly/lVSnkj を参照します。

静解析を最適に使用

静解析は困難であるし、も厳密なものはないと考えられます。 多くの場合、コントラクト情報だけでは、大幅に、ビルド プロセスが低下すること確認するには、最高の意図にコードを入力することも行われます。 いくつかの契約とその後の分析の使用を最適化するための方法です。

最初に、特殊なビルド構成を作成し、静的のみにチェックを有効にするします。 定期的に切り替えて、フィードバックを取得し、適用します。 操作が完了すると、静解析の追加負担がないいつものソリューションを構築するを戻します。

第二に、段階的な部分の契約を使用して行います。 コードでは、契約書を適用が、アセンブリ レベルのコントラクトを無効にします。 これは、アセンブリのプロパティには、次の属性を追加するだけで実行できます。

[assembly: ContractVerification(false)]

契約のだけは、現在注目しているを確認します。 次に、再度有効にします。 クラス、メソッド、またはアセンブリ. 値が true のと同じ属性を使用します。

まとめ

静解析を実行せず、ソース コードの正確さを評価することを目的とする手法です。 これを行ういくつかのツールはさまざまな範囲にします。 1 つは、コンパイラだけです。 もう 1 つの解析ツールを静的チェッカーは： が実行可能ファイルは、通常は、ビルド プロセスに統合されています。 します。NET Framework でコード コントラクトのコードの情報を学ぶことで特別な静的チェッカーを使用できます。 チェッカーは、次の点を評価し、潜在的なエラーを強調表示し、契約違反します。

複雑性を継続的に増加して時間の開発チームを常に実行、静解析の統合ビルドでは少し時間を節約しより重要なは、保存、ソフトウェアだけで万ヒット悪いバグから。

Dino Esposito は、『Programming Microsoft ASP.NET MVC』(Microsoft Press、2010 年) の著者であり、『Microsoft .NET: Architecting Applications for the Enterprise』(Microsoft Press、2008 年) の共著者です) の共著者でもあります。Esposito はイタリアに在住し、世界各国で開催される業界のイベントで頻繁に講演しています。Twitter ( twitter.com/despos、英語) で彼をフォローしてください。

この記事を確認するのには次の技術のエキスパートに感謝： Manuel Fahndrich