Nullable 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

• Anonymous
  July 16, 2008
  PingBack from http://wordnew.acne-reveiw.info/?p=9471

• Anonymous
  July 16, 2008
  Now all we need is a non-nullable type system or annotation so we can know a reference type can't be null.

• Anonymous
  July 20, 2008
  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

• Anonymous
  September 08, 2008
  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>

• Anonymous
  October 11, 2008
  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?

• Anonymous
  February 22, 2009
  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

• Anonymous
  September 23, 2009
  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!