問題タブ [code-contracts]

コード分​​析とコード コントラクトを組み合わせて使用​​すると、次のような多くの警告が表示されます

CA1062 : Microsoft.Design : 外部から見えるメソッド 'Foo.Bar(Log)' で、パラメーター 'log' を使用する前に検証してください。

Foo.Bar には、検証するコントラクトがありlogます。

FxCop にコード コントラクトを理解させる方法はありますか?

重複の可能性：
負にできない値にはC＃でuintを使用する必要がありますか？

（大まかにMaxValue:)）2^31と2^32の関係は関係ないとします。一方でuintは、それは自明であるため、使用することは良いように思われます。それは、ある値が決して負になることはないかもしれないことを示します（そして約束しますか？）。ただし、intより一般的であり、キャストはしばしば不便です。intを使用して、常にコードコントラクトで補足することができます（誰もが今では.Net 4.0に移行していますよね？）標準ライブラリはプロパティを使用しintますが、それらが負になることはありません。それで、それはほとんどの場合よりも優れていることはあなたにとって明らかですか、それとももっと複雑ですか？LengthSizeintuint

この質問が明確に述べられていないことがわかった場合は、質問してください。

ありがとう。

編集：うん、だまされたように見える。ただし、非常に小さな質問です。値が負でない場合に、この特定のケースでプロパティ/関数をコードコントラクト/アサートステートメントで補足する方法の良い例を教えてください。

私は通常のデータコンテキストを使用して次のコードを持っていますが、これはうまく機能します：

ただし、フィルターを次のような拡張メソッドに変換すると、次のようになります。

次の警告が表示されます。

警告：CodeContracts：証明されていないものが必要です：source！= null

私は Code Contracts で遊んでいますが、これまで見てきたものが本当に気に入っています。彼らは、自分の仮定を評価して明示的に宣言するように勧めてくれます。これは、コントラクトを追加するコードで考慮していなかったいくつかのコーナー ケースを特定するのにすでに役立ちました。現在、私はより洗練された不変条件を適用しようとして遊んでいます。現在、証明に失敗しているケースが 1 つあります。単純に Contract.Assume 呼び出しを追加する以外に、これを修正できる方法があるかどうか知りたいです。読みやすくするために削除された問題のクラスを次に示します。

クラスの不変条件が証明可能になるように、ReserveSpace で Contract 呼び出しを構造化する方法に興味があります。特に、(Length <= Buffer.Length) および (CurrentByte <= Length) について文句を言います。新しいバッファーを作成して参照を再割り当てしているため、 (Length <= Buffer.Length) が満たされていることがわかりません。不変条件が満たされていると仮定するを追加する唯一のオプションはありますか?

コードコントラクトとlinqに問題があります。問題を次のコードサンプルに絞り込むことができました。そして今、私は立ち往生しています。

私のlinqチェーンの何が問題になっていますか？ForPersonの呼び出しを分析するときに、なぜ「不平を言う」のではないのですか？

編集：ForPersonメソッドの戻りタイプが文字列からIQueryableに変更されました。（私の悪い）

私はついに、.NET 3.5/4.0フレームワークに追加されたすべての新しいものに追いつきました。ここ数日、私はCodeContractsを使用しており、それらを気に入ってもらうために一生懸命努力しています。他の人がC＃でのCodeContractsの実装についてどう思うか興味がありますか？具体的には、インターフェイスのコントラクトクラス、コントラクトインバリアントのコントラクトメソッドなどをどのように整理していますか？

私は契約が提供する検証が好きです、一見すると彼らは見栄えがします。数行の簡単な行で、コードを実行する前に、いくつかの優れたビルドチェックを取得できます。残念ながら、コードコントラクトがC＃で実装されているという感覚を乗り越えるのに苦労しています。彼らは、コントラクトを文書化するよりもコードを乱雑にしているのです。そして、コントラクトを最大限に活用するために、私は自分のコードに仮定や主張などを散らかしています（これは良いことだと言う人もいます）。しかし、以下の私の例のいくつかが示すように、それは単一の単純な行を4行または5行に変換し、代替アプローチ（つまり、アサート、例外など）に対する私の意見では実際には十分な価値を追加しません。

現在、私の最大の不満は次のとおりです。

インターフェース契約：

これは私にはそのような手がかりのように感じます。属性または何らかの形式の組み込み言語サポートを介して、要件を文書化するためのよりクリーンな方法があればいいのにと思います。インターフェイスを実装する抽象クラスを実装する必要があるという事実は、コントラクトを指定できるようにするために、せいぜい退屈に思えます。

コード膨張：

すぐに利用できる情報を検証するためだけに、いくつかの仮定が必要です。アナライザーが知っているのは、Typeで動作しているため、その限られた知識で動作する必要があることだけですが、1行のコードで次のように書き直す必要があることは不満です。

文書化しておくためだけに（はい、ContractVerificationAttributeを使用してメソッド/クラスなどでこれをオフにするか、SuppressMessageAttribbuteを使用して特定のメッセージをターゲットにすることができますが、コードがすぐに抑制などで散らかってしまうため、目的が損なわれるようです。

また、次のようなケースを取る

objはnullでない必要があり、変更できない読み取り専用フィールドに設定されていますが、nullを返さないというプロパティ要件を証明できるように、クラスに「マークアップ」メソッドを追加する必要があります。

まだまだありますが、私はおそらく十分に怒鳴っていると思いました。コードコントラクトを「好き」にして、このコードの乱雑さを解消するために、私よりもはるかに賢い人々の洞察を本当に感謝しています。コードをより適切に構造化する方法、不安定さの問題を回避する方法などについての洞察をいただければ幸いです。

ありがとう！

次のように開始するメソッドがあります。

GetUnboundTagsRecursively の実装のコントラクト (同じクラスで実装) は次のようになります。

静的アナライザーは、ResolveTag のタグ割り当て行での失敗をメッセージで示しています"requires unproven: source != null"。私はこれを数回調べましたが、なぜこれが起こるのかわかりません。sourceこれは、拡張メソッドのパラメーターへの参照であると想定していますToArray()。私のメソッドは、結果が null ではないことを保証すると述べているため、これは、のソースToArray()も null ではないことを暗示しているように思われます。私は何が欠けていますか？

追加情報: IEnumerable を返すメソッドは、yield リターン コールで実装されています。列挙子の魔法が何らかの形でコード契約をいじっているのではないかと思っています...

yield return を使用するのではなく、空の配列を返すように実装を変更しようとしましたが、それはコントラクトを渡します。明らかに、yield return を使用するメソッドの問題です。誰もこれを回避する方法を知っていますか?

コントラクト DLL の IL を調べたところ、実際には、列挙子の実装のためにコントラクト呼び出しが MoveNext() に配置されています。

Contract.Result 呼び出しが実際には間違った型を使用しているため、これは興味深いことです (MoveNext が bool を返すため)。

わかりました、コード コントラクトに関する別の質問があります。私は次のようなインターフェイス メソッドのコントラクトを持っています (明確にするために他のメソッドは省略されています)。

次のようなインターフェイスを使用するコードがあります。

AddRequestednull 以外の入力パラメーターが必要なため (Requires コントラクトを持つインターフェイスを実装する)、渡される subGroup で「requires unproven: group != null」エラーが発生しますAddRequested。ForAll 構文を正しく使用していますか? そうであり、ソルバーが単に理解していない場合、ソルバーがコントラクトを認識できるようにする別の方法はありますか、または GetAllGroups() が呼び出されるたびに Assume を使用する必要がありますか?

私は.NET4.0コードコントラクトを研究していて、これに関する質問でスタックオーバーフローも調べています。

コードコントラクトを使用するサンプルコードに出くわしたことがないので、疑問に思います。これは本当に便利ですか？それとも、コードが特定の複雑さに達する唯一の有用なものですか？コードコントラクトを使用している人がいて、本当に喜んでいますか？

すべてのコードコントラクトは、コンパイル時に出入りする値を把握することを試みることができることに加えて、メソッドに何が入り、何が出て行くかについてのアサーションであるように私には思えます...しかし、これは進んでいますすべてのメソッドでより多くのコードを必要とする..それは価値がありますか？

私が気付いた利点は、ユニットテストの最初の行としてコードコントラクトを使用できるように見えることです...次に、ユニットテストを作成するときに、コードコントラクトがすでにカバーしているため、より基本的なテストの作成を回避できます。 。 本当 ？

コントラクトはWCFコールで機能しますか？プロキシが自動的に作成されるので、変更できないと思います。

public void Foo(string bar)呼び出し元が の null 値で呼び出してはならないメソッドがあるとしますbar。private void FooImpl(string bar)の実際の作業を行うというメソッドも持っているとしましょうFoo。もちろん、FooImplがパブリック インターフェイスであるにもかかわらず、実際には が非 null である必要があります。そして、.NET 4.0 コード コントラクトを使用して、この非 null 性を強制したいとします。barFoo

契約書はどこに置く？

私がこれを行う場合：

Foo次に、静的チェッカーは が null の可能性がある値で呼び出していると不平を言い、FooImplnull 以外のコントラクトを に追加することを提案しFooます。わかりましたので、契約チェック/例外スローを実装メソッドに委譲することはできないと思います。

しかし、それをパブリックインターフェイスに入れようとすると、つまり:

次に、静的チェッカーは、が null 値FooImplで呼び出さContainsれる可能性があると不平を言います---FooImplコード内で呼び出される唯一の場所がfrom であってもFoo、それ自体が null 値で呼び出されることは決してないことが保証されFooImplます。

では、同じコントラクトを 2 回含める必要がありますか? または、静的チェッカーを無視する必要がありますか? 私はそれが一種の忙しい仕事の源であり、頼りにすべきではないことを知っていますが、この基本的でおそらく一般的なシナリオを処理する何らかの方法があることを願っています.