在c#中,int和Int32是同一个东西,但我读过很多次int比Int32更受欢迎,没有给出原因。这是有原因的吗,我应该在意吗?


当前回答

我总是在定义变量时使用别名类型(int, string等),在访问静态方法时使用真实名称:

int x, y;
...
String.Format ("{0}x{1}", x, y);

看到像int.TryParse()这样的东西似乎很难看。除了风格,我这么做没有别的原因。

其他回答

前一段时间,我在微软做一个项目,当时微软。net CLR产品团队的人来拜访我们。这个人编写了例子,当他定义变量时,他使用“Int32”与“int”和“String”与“String”。

我记得在微软的其他示例代码中见过这种样式。所以,我做了一些研究,发现每个人都说“Int32”和“int”之间没有区别,除了语法着色。事实上,我发现很多材料都建议您使用“Int32”使您的代码更具可读性。所以,我采用了这种风格。

前几天我确实发现了不同!编译器不允许你使用" Int32 "输入enum,但当你使用" int "时,它允许你输入enum。别问我为什么,因为我还不知道。

例子:

public  enum MyEnum : Int32
{
    AEnum = 0
}

这个作品。

public enum MyEnum : int
{
    AEnum = 0
}

取自:Int32符号vs. int

它们都声明了32位整数,正如其他作者所述,使用哪一个主要是语法风格的问题。然而,他们并不总是以同样的方式表现。例如,c#编译器不允许这样做:

public enum MyEnum : Int32
{
    member1 = 0
}

但是它允许这样做:

public enum MyEnum : int
{
    member1 = 0
}

图。

我总是在定义变量时使用别名类型(int, string等),在访问静态方法时使用真实名称:

int x, y;
...
String.Format ("{0}x{1}", x, y);

看到像int.TryParse()这样的东西似乎很难看。除了风格,我这么做没有别的原因。

当您只需要处理一种语言时,类型的字节大小就不太有趣了(对于那些不需要提醒自己数学溢出的代码)。有趣的部分是当你在一种语言和另一种语言之间建立桥梁,c#到COM对象,等等,或者你正在做一些位转移或屏蔽,你需要提醒自己(和你的代码审查同事)数据的大小。

在实践中,我通常使用Int32来提醒自己它们的大小,因为我确实写托管c++(例如桥接到c#)以及非托管/本机c++。

你可能知道,在c#中是64位,但在原生c++中,它最终是32位,或者char是unicode/16位,而在c++中是8位。但是我们是怎么知道的呢?答案是,因为我们已经在手册上查过了,上面是这么说的。

随着时间的推移和经验的积累,当你在c#和其他语言之间编写代码时,你会开始更加注重类型(这里的一些读者会想“为什么你会这样做?”),但恕我直言,我认为这是一个更好的实践,因为我不记得我上周写了什么(或者我不必在我的API文档中指定“此参数是32位整数”)。

在f#中(尽管我从未使用过它),它们定义了int, int32和nativeint。同样的问题也会出现,“我该用哪一个?”正如其他人所提到的,在大多数情况下,它不应该是重要的(应该是透明的)。但我个人会选择int32和uint32来消除歧义。

我想这取决于你在编写什么应用程序,谁在使用它,你和你的团队遵循什么编码实践,等等,来证明什么时候使用Int32。

附录: 顺便说一句,自从我几年前回答了这个问题之后,我就开始同时使用f#和Rust了。f#,它都是关于类型推断,以及c#和f#之间的桥接/互操作,本机类型匹配,所以不用担心;我很少需要在f#中显式地定义类型(如果不使用类型推断,这几乎是一种罪过)。在Rust中,他们完全消除了这种歧义,你必须使用i32 vs u32;总而言之,减少歧义有助于减少bug。

int和Int32是一样的。int是Int32的别名。