Definitely, I know the basic differences between unsigned integers (uint
) and signed integers (int
).
I noticed that in .NET public classes, a property called Length
is always using signed integers.
Maybe this is because unsigned integers are not CLS compliant.
However, for example, in my static function:
public static double GetDistributionDispersion(int tokens, int[] positions)
The parameter tokens
and all elements in positions
cannot be negative. If it's negative, the final result is useless. So if I use int
both for tokens
and positions
, I have to check the values every time this function is called (and return non-sense values or throw exceptions if negative values found???), which is tedious.
OK, then we should use uint
for both parameters. This really makes sense to me.
I found, however, as in a lot of public APIs, they are almost always using int
. Does that mean inside their implementation, they always check the negativeness of each value (if it is supposed to be non-negative)?
So, in a word, what should I do?
I could provide two cases:
Should we use different schemes for these two cases?
Peter
P.S.: I did do a lot of research, and there is still no reason to convince me not to use uint
:-)
I see three options.
Use uint
. The framework doesn't because it's not CLS compliant. But do you have to be CLS compliant? (There are also some not-fun issues with arithmetic that crop up; it's not fun to cast all over the place. I tend to void uint
for this reason).
Use int
but use contracts:
Contract.Requires(tokens >= 0);
Contract.Requires(Contract.ForAll(positions, position => position >= 0));
Make it explicit it exactly what you require.
Create a custom type that encapsulates the requirement:
struct Foo {
public readonly int foo;
public Foo(int foo) {
Contract.Requires(foo >= 0);
this.foo = foo;
}
public static implicit operator int(Foo foo) {
return this.foo;
}
public static explicit operator Foo(int foo) {
return new Foo(foo);
}
}
Then:
public static double GetDistributionDispersion(Foo tokens, Foo[] positions) { }
Ah, nice. We don't have to worry about it in our method. If we're getting a Foo
, it's valid.
You have a reason for requiring non-negativity in your domain. It's modeling some concept. Might as well promote that concept to a bonafide object in your domain model and encapsulate all the concepts that come with it.
I use uint.
Yes, other answers are all correct... But I prefer then uint for one reason:
Make interface more clear. If a parameter (or a returned value) is unsigned, it is because it cannot be negative (has you seen a negative collection count?). Otherwise, I need to check parameters, document parameters (and returned value) that cannot be negative; then I need to write additional unit tests for checking parameters and returned values (wow, and someone would complain for doing casts? Are int casts so frequent? No, by my experience).
Additionally, users are required to test returned values negativity, which may be worse.
I don't mind about CLS compliace, so why I should be? From my point of view, the question should be reversed: why should I use ints when value cannot be negative?
For the point of returning negative value for additional information (errors, for example...): I don't like so C-ish design. I think there may be a more modern design to accomplish this (i.e. use of Exceptions, or alterntively use of out values and boolean returned values).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With