Use uint or int

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开发者_如何学Python 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:

1. This function will only be called by myself in my own solution;
2. This function will be used as a library by others in other team.

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

Yes go for int. I once tried to go uint myself only to refactor everything again as soon as I had my share of annoying casts in my lib. I guess the decision to go for int is for historical reasons where often a result of -1 indicates some sort of error (for example in IndexOf).

int. it gives more flexibility when you need to do a API change in the near future. such as negative indexes are often used by python to indicate reversed counting from the end of string.

values also turns negative when overflows, assertion will catch it.

its a trade off for speed vs robustness.

As you read it violates the Common Language Specification rules, but then how often will the function be used and in case it going to be clubbed up with other method its normal for them to expect int as parameter which would get you into the trouble of casting the values.

If you are going to make it available as a library then its better sticking to the conventional int else you need to implicitly take care of conditions wherein you might not get a positive value which would mean littering the checks across the pages.

Interesting Read - SO link