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.
NotNull sounded good, but was not
Posted by Jmaxxz on February 12, 2011
https://jmaxxz.com/blog/?p=322
Previous Post
Jmaxxz.Deet 98.9% null proof
Jmaxxz.Deet 98.9% null proof
Next Post
Airborne Mouse
Airborne Mouse
Michael Welch
/ March 19, 2012Hmm, 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
/ March 19, 2012For 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.ThrowIfNull(“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.