My Links

News

Welcome to my blog! I'm a Sr. Software Development Engineer in the Seattle area, who has been performing C++/C#/Java development for over 20 years, but have definitely learned that there is always more to learn!

All thoughts and opinions expressed in my blog and my comments are my own and do not represent the thoughts of my employer.

Little Wonders

vNext

I’ve been working with a wonderful team on a major release where I work, which has had the side-effect of occupying most of my spare time preparing, testing, and monitoring. However, I do have this Little Wonder tidbit to offer today.

Introduction

The IComparable<T> interface is great for implementing a natural order for a data type. It’s a very simple interface with a single method Compare() that compares two items of type T and returns an integer result.

So what do we expect for the integer return value? It’s a pseudo-relative measure of the ordering of x and y, which returns an integer value in much the same way C++ returns an integer result from the strcmp() c-style string comparison function:

If x == y, returns 0.

If x > y, returns > 0 (often +1, but not guaranteed)

If x < y, returns < 0 (often –1, but not guaranteed)

Notice that the comparison operator used to evaluate against zero should be the same comparison operator you’d use as the comparison operator between x and y. That is, if you want to see if x > y you’d see if the result > 0.

The Problem: Comparing With null Can Be Messy

This gets tricky though when you have null arguments. According to the MSDN, a null value should be considered equal to a null value, and a null value should be less than a non-null value. So taking this into account we’d expect this instead:

If x == y (or both null), return 0.

If x > y (or y only is null), return > 0.

If x < y (or x only is null), return < 0.

But here’s the problem – if x is null, what happens when we attempt to call CompareTo() off of x?

1:// what happens if x is null?

2: x.CompareTo(y);

It’s pretty obvious we’ll get a NullReferenceException here. Now, we could guard against this before calling CompareTo():

Of course, we could shorten this with the ternary operator (?:), but even then it’s ugly repetitive code:

1:int result = (x == null)

2: ? ((y == null) ? 0 : -1)

3: : x.CompareTo(y);

Fortunately, the null issues can be cleaned up by drafting in an external Comparer.

The Soltuion: Comparer<T>.Default

You can always develop your own instance of IComparer<T> for the job of comparing two items of the same type. The nice thing about a IComparer is its is independent of the things you are comparing, so this makes it great for comparing in an alternative order to the natural order of items, or when one or both of the items may be null.

1:publicclass NullableIntComparer : IComparer<int?>

2: {

3:publicint Compare(int? x, int? y)

4: {

5:return (x == null)

6: ? ((y == null) ? 0 : -1)

7: : x.Value.CompareTo(y);

8: }

9: }

Now, if you want a custom sort -- especially on large-grained objects with different possible sort fields -- this is the best option you have. But if you just want to take advantage of the natural ordering of the type, there is an easier way.

If the type you want to compare already implements IComparable<T> or if the type is System.Nullable<T> where T implements IComparable, there is a class in the System.Collections.Generic namespace called Comparer<T> which exposes a property called Default that will create a singleton that represents the default comparer for items of that type. For example:

1:// compares integers

2: var intComparer = Comparer<int>.Default;

3:

4:// compares DateTime values

5: var dateTimeComparer = Comparer<DateTime>.Default;

6:

7:// compares nullable doubles using the null rules!

8: var nullableDoubleComparer = Comparer<double?>.Default;

This helps you avoid having to remember the messy null logic and makes it to compare objects where you don’t know if one or more of the values is null.

This works especially well when creating say an IComparer<T> implementation for a large-grained class that may or may not contain a field. For example, let’s say you want to create a sorting comparer for a stock open price, but if the market the stock is trading in hasn’t opened yet, the open price will be null. We could handle this (assuming a reasonable Quote definition) like:

16:// I had left this off originally for brevity, but to avoid confusion...

17:// Note: ReferenceEquals checks if both same reference (or null)

18:if (ReferenceEquals(x, y)) return 0;

19:if (x == null) return -1;

20:if (y == null) return 1;

21:

22:// now can uses the Comparer<T>.Default to handle null-ness of the field

23:return Comparer<double?>.Default.Compare(x.Open, y.Open);

24: }

25: }

Summary

Defining a custom comparer is often needed for non-natural ordering or defining alternative orderings, but when you just want to compare two items that are IComparable<T> and account for null behavior, you can use the Comparer<T>.Default comparer generator and you’ll never have to worry about correct null value sorting again.