NotNull sounded good, but was not

A couple weeks back I published Jmaxxz.Deet, a software library which brought reference types to the C# language which were guaranteed never to be null. While I maintain that null references are an indication of poor design and should be avoided at all cost, I am forced to admit that Jmaxxz.Deet is not the answer. Over the course of the week following its release I adopted into all my code. I found that the syntactical complexity it added significantly reduced the readability of my code. This added a certain level of cost to maintaining any code written using Deet.  In my estimation this cost is not worth the benefit of formal declarations of the nonnull state of reference types. The only way something like Deet become a reasonable solution is if it has first class compiler support, or through the use of a tool like PostSharp to add it in as a post compile step so as not to pollute the code-base with noisy declarations.

  • Hmm, we could write extension methods for it (like we did for Optional) so as to take advantage of linq.

    Even if it’s still not practical, it might be fun to play around with it.

    • jmaxxz

      For practicality I have settled on an extension method hanging off of object which does the null check for me. Example usage:

      void Foo(Person bar)
      //bar can not be null on this line

      The downside to this is there is nothing in the contract for Foo that tells the compiler bar can not be null.