我应该在C＃中将uint用作不能为负的值吗？

我刚刚尝试实现一个类，其中使用许多length / count属性等uint代替int。但是，在这样做的同时，我注意到这样做实际上是很痛苦的，就像没有人真正想要这样做那样。

几乎所有提供整数类型的东西都返回int，因此需要在多个点上进行强制转换。我想构造一个StringBuffer缓冲区长度默认为该类中字段之一的。也需要强制转换。

所以我想知道我是否应该回到int这里。无论如何，我当然不会使用整个范围。我只是认为，因为我在那里处理的东西不可能完全是负面的（如果是的话，那将是一个错误），所以实际使用它是一个好主意uint。

PS：我看到了这个问题，这至少可以解释为什么框架本身总是使用，int但是即使在自己的代码中，遵守它实际上也很麻烦，uint这使我认为显然并不需要它。

虽然严格来说，您应该将uint变量用于包含非负整数的变量，但您却发现它并非总是可行的原因之一。

在这种情况下，我认为必须进行强制转换会导致可读性的降低是不值得的。

我还将在其他答案中添加使用uint作为公共字段，属性，方法，参数等的类型，这违反了公共语言规范规则，应尽可能避免使用。

负值通常用于表示错误情况，并且操作的大小通常由函数调用返回；因此，如果不使用异常机制，则负值可能表示错误。

还请注意，.NET通常建立在直接的C库上，因此继续使用此约定是明智的。如果您需要更大的索引空间，则可以打破不同错误信号传递机制的约定。

我个人的感觉是，您应该只坚持int。仅仅为了收回.NET不太可能让您使用的数值范围，几乎不应该在每个属性访问中添加强制类型转换。

使用int还有助于检测操作中的整数溢出。

IMO，使用的缺点uint是它掩盖了错误条件。以下代码的等效项不是很好：

if (len < 0)
    terminate_program("length attained impossible value.");

当然，您的程序一开始就不会误算任何东西，但我认为它们也应该编写为快速检测数值错误而不会传播。在MaxValue为2 ^ 31的情况下，我说的是useint以及System.Diagnostics.Debug.Assert()上面所举例说明的正确使用和相应的错误检查。

如果您确实使用uint它，请与一起使用checked以防止下溢并获得相同的结果。但是我发现，将检查应用到出于某种目的而使用强制类型转换的现有代码有些困难。

如果不需要，不要上游游泳。不使用强制转换对代码进行编码会使代码更具可读性。此外，如果您的可能值适合int以内，那么使用int也不成问题。

如果您担心自己可能会溢出一个int，则一定要在其中进行..但不要过早地进行优化。

我要说的是，最小化强制类型转换所带来的更好的可读性胜过使用int带来的Bug风险略有提高。

如果要检查值是否为正，则更好的方法可能是使用assert（注意，这只是一种调试技术-您应确保在最终代码中永远不会发生这种情况）。

using System.Diagnostics;
...
Debug.Assert (i > 0);