Contract Killers

Seriously, is this the most succinct way of expressing this?

public interface IRequestFailure
    string FailureMessage { get; }

public class RequestFailureContract : IRequestFailure
    public string FailureMessage
        get { 
            Contract.Ensures(Contract.Result<string>() != null);
            return null;

Personally, I would prefer to write this:

public interface IRequestFailure
    string! FailureMessage { get; }

If you’re currently thinking there’s something very wrong with code contracts in C# you’d be right.  What’s wrong is that code contracts aren’t actually a language feature.  They’re implemented as a post-compilation rewrite.  Don’t get me wrong, it’s really impressive that they achieved it this way, and they’re still an improvement on what went before, but I can’t help feeling they lost sight of the ultimate goal on this one.  Worse, enforcing code contracts is achieved by a DevLabs download that’s feature-locked to particular versions of Visual Studio.  I’m pretty sure I missed the part of the Liskov Substitution Principle that said “This doesn’t apply if you happen to be running Visual Studio Professional”.

Published by

Julian Birch

Full time dad, does a bit of coding on the side.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s