C# sorting - a subtle mistake

Just a second! 🫷
If you are here, it means that you are a software developer. So, you know that storage, networking, and domain management have a cost .

If you want to support this blog, please ensure that you have disabled the adblocker for this site. I configured Google AdSense to show as few ADS as possible - I don't want to bother you with lots of ads, but I still need to add some to pay for the resources for my site.

Thank you for your understanding.
- Davide

Recently I’ve learned a funny (ehm…) thing.

The guilty

It isn’t true that the inverse of a negative number is 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);
}

But what if we consider edge cases?

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

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).

This article first appeared on Code4IT

Conclusion

This example teaches us that we must know the basics of a language not only in terms of syntax but also in terms of inner handling. If we just used int without knowing how it is made, we would fall into this mistake without knowing why.