title: Really trying to like CodeContracts in C#
body: <p>I am finally playing catchup with everything new that has been added in to the .NET 3.5/4.0 Frameworks. The last few days I have been working with CodeContracts and I am really trying hard to like them. I am curious what other people think of the implementation of CodeContracts in C#? Specifically, how are people organizing things like Contract classes for interfaces, contract methods for Contract Invariants etc?</p>
  
  <p>I like the validation that contracts provide, at first glance they look great. With a few simple lines I can get some nice build checking before I even run my code. Unfortunately, I am having a hard time getting over the feeling that the way that code contracts are implement in C#, they are cluttering up my code more than they are documenting contracts. And to take full advantage of contracts, I am littering my code with assumptions and asserts etc (which I know some will say is a good thing); but as some of my examples below will show, it turns a single simple line in to 4 or 5 lines, and doesn't really add sufficient value in my opinion over alternative approaches (i.e., asserts, exceptions etc).</p>
  
  <p>Currently, my greatest frustrations are:</p>
  
  <p>Interface Contracts:</p>
  
  <pre><code>[ContractClass(typeof(IInterfaceContract))]
    public interface IInterface
    {
      Object Method(Object arg);
    }
  
    [ContractClassFor(typeof(IInterface))]
    internal abstract class IInterfaceContract
    {
      private IInterfaceContract() { }
  
      Object IInterface.Method(Object arg)
      {
        Contract.Requires(arg != null);
        Contract.Ensures(Contract.Result&lt;Object&gt;() != null);
        return default(Object);
      }
    }
  </code></pre>
  
  <p>This feels like such a cludge to me, I wish there was a cleaner way to document requirements, either via attributes or some form of built in language support. The fact that I have to implement an abstract class that implements my interface, just so I can specify the contract seems tedious at best.</p>
  
  <p>Code Bloat:</p>
  
  <pre><code>typeof(Action&lt;&gt;).MakeGenericType(typeof(Object);
  </code></pre>
  
  <p>Requires several assumptions just to verify information that is readily available. I appreciate that all the analyzer knows is that it is operating on Type and thus must work on that limited knowledge, but it still frustrates me that a single line of code requires me to re-write as</p>
  
  <pre><code>var genericAction = typeof(Action&lt;&gt;);
  
  Contract.Assume(genericAction.IsGenericType);
  Contract.Assume(genericAction.GetGenericArguments().Length == 1);
  
  genericAction.MakeGenericType(typeof(Object));
  </code></pre>
  
  <p>Just to keep things documented (yes I know I can use ContractVerificationAttribute to turn this off for a method/class etc, or SuppressMessageAttribbute to target specific messages, but that seems to defeat the purpose as your code would quickly become littered with suppressions etc. </p>
  
  <p>In addition, taking a case like</p>
  
  <pre><code>  public class MyClass
      : IInterface
    {
      private readonly Object _obj;
  
      public Object Property
      {
        get
        {
          Contract.Ensures(Contract.Result&lt;Object&gt;() != null);
          return _obj;
        }
      }
  
      public MyClass(Object obj)
      {
        Contract.Requires(obj != null);
  
        _obj = obj;
      }
    }
  </code></pre>
  
  <p>obj is required to be not null, and is set to a readonly field that cannot be changed, yet I am still required to add a "markup" method to my class so that my property requirement to not return null can be proven:</p>
  
  <pre><code>[ContractInvariantMethod]
  private void ObjectInvariant()
  {
    Contract.Invariant(_obj != null);
  }
  </code></pre>
  
  <p>There is more, but I figured I have probably ranted enough, and I would really appreciate the insight of people much smarter than me to help me "like" Code Contracts and make this feeling of code clutter go away. Any insight on how to better structure code, workaround wonkiness issues etc would be greatly appreciated.</p>
  
  <p>Thanks!</p>