List<T>.Sort() and Array.Sort() don't know how to compare your custom type — until you tell them, once, with a single method.

You've called .Sort() on a List<int> or List<string> without a second thought — it just works, because .NET already knows how to compare numbers and strings. Now try it on a list of your own type:

This doesn't fail to compile — it fails at runtime, with a somewhat cryptic message. The real problem: Sort() needs some way to decide "which of these two Products comes first?" and nothing you've written tells it how. int and string already answer that question, because they implement an interface called IComparable<T> — and once your own types do too, sorting them becomes just as effortless.

In this lesson, you'll implement IComparable<T> to give a custom type a natural ordering, see exactly how List<T>.Sort() and Array.Sort() use it, and briefly contrast it with IComparer<T> — the interface you met in passing back in the covariance lesson.

What Is It?

The Simple Explanation

IComparable<T> is how a type declares its own natural ordering — "given another instance of me, I can tell you whether I come before it, after it, or we're the same." It's the single method that int, string, DateTime, and every other built-in sortable type implement, and it's exactly the method missing from the broken Product example above.

The Technical Definition

IComparable<T> is a generic interface with exactly one member:

CompareTo returns an int whose sign — not its exact value — carries the meaning:

• Negative — this instance comes before other.
• Zero — this instance is considered equal to other, for ordering purposes.
• Positive — this instance comes after other.

Notice the in T — this is the contravariant interface you already met in the covariance lesson, which is exactly why it made sense as one of that lesson's running examples.

Why Does It Exist?

The Problem

List<T>.Sort() and Array.Sort() are generic — the exact same sorting algorithm has to work correctly for a List<int>, a List<string>, and a List<Product>, without the sorting code itself knowing anything about what a Product even is. A sorting algorithm's entire job boils down to repeatedly asking "which of these two elements comes first?" — but it has no way to answer that question for an arbitrary type on its own; Price > Price means something for two decimals, but the algorithm doesn't know to compare Price at all, let alone that it should.

The Solution

IComparable<T> is exactly the interface constraint you met two lessons ago in the constraints module — a contract the sorting algorithm can rely on without knowing anything about the type itself. Once Product implements IComparable<Product>, Sort() simply calls CompareTo on pairs of elements as many times as its algorithm needs, and lets your implementation decide what "comes first" actually means for a Product.

Big Picture

products.Sort();
    ↓
Sort's algorithm repeatedly picks two elements, a and b,
and needs to know: does a come before or after b?
    ↓
calls a.CompareTo(b)
    ↓
your CompareTo runs: Price.CompareTo(other.Price)
    ↓
returns negative / zero / positive
    ↓
Sort's algorithm uses that answer to decide where to place them
    ↓
repeats until the whole list is ordered

How It Works

public class Product : IComparable<Product>
{
    public string Name { get; init; } = "";
    public decimal Price { get; init; }
    // ...
}

public int CompareTo(Product? other)
{
    if (other is null) return 1;   // by convention, anything comes "after" null
    return Price.CompareTo(other.Price);   // decimal already implements IComparable<decimal>
}

products.Sort();          //  now works — ascending by Price
Array.Sort(productArray);  //  same story for arrays

Simple Example

Code → Meaning → Result:

• CompareTo delegates entirely to decimal.CompareTo, so Product's ordering is just "whichever Price is smaller" — no manual comparison logic needed.
• products.Sort(), which threw at runtime before, now works exactly like sorting a list of int or string.
• The output is ascending by price — that's the "natural ordering" this Product type has now defined for itself.

Real-World Example

Sorting a product catalog by a multi-part rule — in stock first, then by price — is a realistic scenario where CompareTo needs to combine more than one field, in priority order.

This is the pattern real production code uses constantly: compare the highest-priority field first, and only fall through to the next field when the first comparison is a tie (0) — exactly the same technique behind LINQ's OrderBy().ThenBy(), which you'll meet properly in a later module.

Analogy

Under the Hood

public class NameComparer : IComparer<Product>
{
    public int Compare(Product? x, Product? y) =>
        string.Compare(x?.Name, y?.Name, StringComparison.Ordinal);
}

products.Sort(new NameComparer());   // overrides the natural ordering, just for this call

Common Confusion

1. CompareTo's exact return value doesn't matter — only its sign does

A common misreading is expecting CompareTo to return something meaningful like "the difference" between two values. It doesn't have to — -1, -100, and int.MinValue all mean exactly the same thing: "comes before." Delegating to decimal.CompareTo or string.Compare, as shown throughout this lesson, is the easiest way to get a correct sign without worrying about the magnitude at all.

2. CompareTo returning 0 is about ordering, not necessarily full equality

It's tempting to assume "CompareTo returns 0" and "Equals returns true" always agree — .NET's own documented guidance is that they generally should, for consistency, but they answer conceptually different questions. Equals asks "are these the same value?"; CompareTo asks "should these be treated as tied for ordering purposes?" The multi-field example above returns 0 from the stock comparison when both are in stock, purely to fall through to the price comparison — that's not a claim the two products are equal.

3. Implementing IComparable<T> doesn't give you < and > automatically

CompareTo is a method call, not an operator — product1.CompareTo(product2) > 0 works, but product1 > product2 still won't compile unless you separately overload the comparison operators (<, >, <=, >=) yourself, typically by delegating to CompareTo inside each operator.

Common Mistakes

Mistake 1 — Calling Sort() without implementing IComparable<T> at all

Wrong — throws InvalidOperationException at runtime, exactly as shown in the Hook:

Correct — implement the interface, or pass an explicit IComparer<T> if you'd rather not modify the type:

Mistake 2 — An inconsistent CompareTo that isn't transitive

Writing comparison logic where a < b and b < c don't reliably imply a < c (for example, comparing by an unstable or randomly-changing value) — sorting algorithms assume transitivity, and violating it produces unpredictable, sometimes infinite-looping sort results. Base CompareTo on stable, well-defined fields, ideally by delegating to already-correct CompareTo implementations like decimal's or string's.

Mistake 3 — Forgetting to handle null in CompareTo

return Price.CompareTo(other.Price); without a null check throws a NullReferenceException if other is null. By convention (and as every example in this lesson shows), a non-null instance is considered to come after null — return a positive number when other is null, exactly as string.CompareTo itself does.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've given a custom type a natural ordering and connected it to Sort(). Let's check your understanding.

You now know how to give your own types a natural ordering. Next: IEquatable<T> — why it exists alongside Equals(object), and how it avoids boxing for value types.

dotnetmadeeasy.com — Learn C# and .NET, the right way.