DEV Community

Cover image for C# sorting - a subtle mistake
Davide Bellone
Davide Bellone

Posted on • Updated on • Originally published at code4it.dev

C# sorting - a subtle mistake

Recently I've noticed a funny (ehm...) thing.

The guilty

It isn't true that the inverse of a negative number is always a positive number. Or, equally, that (x < 0) -> (-x > 0).

You could say "Hey, -(-5) == 5". Yes, that's true.
We can test it this way:

[Test]
public void TestInverse()
{
    int x = -5;
    int y = -x;
    Assert.IsTrue(y > 0);
}
Enter fullscreen mode Exit fullscreen mode

But what if we consider edge cases?

[Test]
public void TestInverse_EdgeCase()
{
    int x = int.MinValue;
    int y = -x;
    Assert.IsTrue(y > 0);
}
Enter fullscreen mode Exit fullscreen mode

It will fail. Miserably.

The reason

The reason is simple: the sign occupies space.
In fact, the range of int is -2,147,483,648 to 2,147,483,647. The inverse of -2,147,483,648 would cause overflow, and returns the same value.

The lesson

Why am I pointing at this?

Imagine you are implementing a CompareTo(x, y) method, you know, the usual one that returns 0 if the values are considered equal, -1 if x < y and 1 if x > y.

You could use this method to sort an array.
Now you want to sort that array descending. What to do?

This edge case explains why it is a terrible idea to use CompareTo(-x, -y). Results can be unexpected.

The best solution is to simply switch the parameters: CompareTo(y, x).

Discussion (0)