Question

I have observed for a while that C# programmers tend to use int everywhere, and rarely resort to uint. But I have never discovered a satisfactory answer as to why.

If interoperability is your goal, uint shouldn’t appear in public APIs because not all CLI languages support unsigned integers. But that doesn’t explain why int is so prevalent, even in internal classes. I suspect this is the reason uint is used sparingly in the BCL.

In C++, if you have an integer for which negative values make no sense, you choose an unsigned integer.

This clearly signifies that negative numbers are not allowed or expected, and the compiler will do some checking for you. I also suspect in the case of array indices, that the JIT can easily drop the lower bounds check.

However, when mixing int and unit types, extra care and casts will be needed.

Should uint be used more? Why?

Answer 1

Your observation of why uint isn’t used in the BCL is the main reason, I suspect.

UInt32 is not CLS Compliant, which means that it is wholly inappropriate for use in public APIs. If you’re going to be using uint in your private API, this will mean doing conversions to other types – and it’s typically easier and safer to just keep the type the same.

I also suspect that this is not as common in C# development, even when C# is the only language being used, primarily because it is not common in the BCL. Developers, in general, try to (thankfully) mimic the style of the framework on which they are building – in C#’s case, this means trying to make your APIs, public and internal, look as much like the .NET Framework BCL as possible. This would mean using uint sparingly.