I like unsigned integers, always have. It’s more correct, concise and expressive, you get more (positive) space out of it and you’re preventing bugs by design. What’s not to love?
I was nooking, you see, and I came across this recommendation:
“Use signed data types (such as Int32 and Int64 instead of unsigned numeric types such as UInt32 and UInt64) wherever possible.”
Say it aint so!
Jeffrey Richter continues:
“This allows the compiler to detect more overflow/underflow errors. In addition, various parts of the class library (such as Array’s and String’s Length properties) are hard-coded to return signed values, and less casting is required as you move these values around in your code.”
Casting is ugly, no argument there but I don’t care much about the overflow/underflow errors. I generally don’t enable overflow checking, there’s no political statement here, it’s just never come up.
And it still feels wrong for me to declare a value signed when I know that it shouldn’t be.
(Richter recommends enabling checking for debug builds, and disabling for release. Sound advice!)
But here’s real the kicker for me:
In addition, unsigned numeric types are not CLS-compliant.
Doh. I did a bit of searching to try and track down why it’s not part of the CLS, and I found that Brad Abrams expresses it best in this post:
“The general feeling among many of us is that the vast majority of programming is done with signed types. Whenever you switch to unsigned types you force a mental model switch (and an ugly cast). In the worst cast you build up a whole parallel world of APIs that take unsigned types. The value of avoiding the ‘< 0' check is not worth the inclusion of generics in the CLS"
Alright, I give in. I’m apparently in the minority, these guys are way smarter than I am, and it is easier, if not more concise. So it goes.
Goodbye for now uint, you’ll always hold a positive place in my heart.
Just like Weezer: