Nullable<T> Usage Guidelines


 


These guidelines were just added as part of an update to the Framework Design Guidelines book (upcomming 2nd edition). Hope you find them useful.


 


Nullable<T> is a simple type added to the .NET Framework 2.0. The type was designed to be able to represent Value Types with “null” values.


Nullable<int> x = null;


Nullable<int> y = 5;


Console.WriteLine(x == null); // prints true


Console.WriteLine(y == null); // prints false


 


Note that C# provides special support for Nullable<T> in the form of language aliases for Nullable types, lifted operators, and the new coalescing operator.


int? x = null; //


long? d = x; // calls cast operator from Int32 to Int64


Console.WriteLine(d??10); // coalescing; prints 10 because d == null


 


þ CONSIDER using Nullable<T> to represent values that might not be present (i.e. optional values). For example, use it when returning a strongly typed record from a database with a property representing an optional table column. 


ý Do NOT use Nullable<T> unless you would use a reference type in a similar manner, taking advantage of the fact that reference type values can be null.


For example, you would not use null to represent optional parameters.


// bad design


public class Foo {


   public Foo(string name, int? id);


}


 


// good design


public class Foo {


   public Foo(string name, int id);


   public Foo(string name);


}


 


ý AVOID using Nullable<bool> to represent a general three-state value.


Nullable<bool> should only be used to represent truly optional Boolean values: true, false, and not available. If you simply want to represent three states (e.g. yes, no, cancel), consider using an enum.


ý AVOID using System.DBNull. Prefer Nullable<T> instead.



Nullable<T> is in general a better representation of optional database values. One thing to consider though it that while Nullable<T> gives you the ability to represent null values, you don’t get database null operational semantics. Specifically, you don’t get null propagation through operators and functions. If you deeply care about the propagation semantics, consider sticking with DBNull.


 

Comments (7)

  1. MichaelGG says:

    Now all we need is a non-nullable type system or annotation so we can know a reference type can’t be null.

  2. General Lessons That I Learned From Waegis : Keyvan Nayyeri shares the lessons he learned from launching Waegis , a spam filter for web sites. Don’t Mix Using Statements And Lambda Expressions : Jared Parsons explains why you do not want to mix using

  3. Siderite says:

    What about when you want to give a nullable parameter to a method that would be null, but you want it to know what kind of nullable it is?

    See this post for details:

    <a>http://siderite.blogspot.com/2007/11/nullable-types-and-their-boxing-in-or.html</a&gt;

  4. jbhamlin says:

    Krzysztof thanks for the guidelines.  

    Questionl, for scenarios like the nullable<bool> to avoid, I had been using CheckState types or enum – but I found the CheckState.Indeterminate to be a value that was a good representaton of the state I needed.  

    Is this something you would avoid?

  5. General Lessons That I Learned From Waegis : Keyvan Nayyeri shares the lessons he learned from launching Waegis , a spam filter for web sites. Don’t Mix Using Statements And Lambda Expressions : Jared Parsons explains why you do not want to mix using

  6. _ivan says:

    Krzysztof,

    What do you think about this post.

    http://isolvable.blogspot.com/2009/09/vbnet-short-circuit-if-statement-and.html

    I’ve experienced the described issue with Nullable(of T) before.

    Thanks!