我应该使用int还是Int32

在C＃中，int并且Int32是同样的事情，但我读了许多那个时代int优于Int32没有给出理由。请问有什么理由吗？

ECMA-334：2006 C＃语言规范（p18）：

每个预定义类型都是系统提供的类型的简写。例如，关键字int指的是struct System.Int32。就样式而言，使用关键字比使用完整的系统类型名称更受青睐。

两者确实是同义词。int看起来会更加熟悉，Int32使32位代码对阅读代码的人更加明确。我倾向于int在我只需要'integer'的Int32地方使用，这里的大小很重要（加密代码，结构），因此将来的维护者将知道int适当地扩大a是安全的，但应注意Int32以相同的方式进行更改。

结果代码将是相同的：区别仅仅是可读性或代码外观之一。

它们都声明了32位整数，并且正如其他张贴者所指出的那样，您使用的主要是语法风格的问题。但是，它们的行为并不总是相同的。例如，C＃编译器不允许这样做：

public enum MyEnum : Int32
{
    member1 = 0
}

但这将允许：

public enum MyEnum : int
{
    member1 = 0
}

去搞清楚。

我总是使用系统类型-例如，Int32而不是int。在阅读Applied .NET Framework编程后，我采用了这种做法-作者Jeffrey Richter为使用完整类型名提供了一个很好的案例。这是我的两点：

1. 类型名称在.NET语言之间可能有所不同。例如，在C＃中，long映射到System.Int64，而在具有托管扩展的C ++中，long映射到Int32。由于在使用.NET时可以混合使用多种语言，因此可以确保无论读者喜欢哪种语言，使用显式类名始终会更加清晰。

2. 许多框架方法将类型名称作为其方法名称的一部分：

   BinaryReader br = new BinaryReader( /* ... */ );
   float val = br.ReadSingle();     // OK, but it looks a little odd...
   Single val = br.ReadSingle();    // OK, and is easier to read

int是C＃关键字，没有歧义。

在大多数情况下，这并不重要，但是有两点与Int32相抵触：

• 您需要一个“使用系统”；声明。使用“ int”不需要使用using语句。
• 可以定义自己的名为Int32的类（这很愚蠢且令人困惑）。int始终表示int。

如前所述，int= Int32。为了安全起见，在实现任何关心数据类型边界的内容时，请务必始终使用int.MinValue/ int.MaxValue。假设.NET决定int现在这样Int64，您的代码将不再依赖于边界。

当您只需要使用一种语言（对于不需要提醒自己有关数学溢出的代码）时，类型的字节大小就不太有趣了。变得有趣的部分是当您在一种语言与另一种语言之间，从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是合理的。

int和之间没有区别Int32，但是正如int许多语言上喜欢的语言关键字一样，它们在样式上也很喜欢（就像stringvs一样String）。

以我的经验，这是很常规的事情。我不知道在Int32上使用int的任何技术原因，但这是：

1. 打字更快。
2. 典型的C＃开发人员更加熟悉。
3. 默认Visual Studio语法突出显示中的其他颜色。

我特别喜欢最后一个。:)

在定义变量时，我总是使用别名类型（int，字符串等），在访问静态方法时，我总是使用真实名称：

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

看到类似int.TryParse（）的东西看起来很丑。除了样式，我没有其他原因。

我知道最佳实践是使用int，并且所有MSDN代码都使用int。但是，据我所知，除了标准化和一致性外，没有其他理由。

尽管它们（大部分）是相同的（请参见下面的一个[bug]区别），但您绝对应该注意并应该使用Int32。

• 16位整数的名称为Int16。对于64位整数，它是Int64，对于32位整数，直观的选择是：int还是Int32？

• Int16，Int32或Int64类型的变量大小的问题是自引用的，但是int类型的变量大小的问题是一个完全有效的问题，无论多么琐碎，都会使人分心，导致造成混乱，浪费时间，阻碍讨论等（这个问题的存在证明了这一点）。

• 使用Int32可以使开发人员意识到他们对类型的选择。int又有多大？哦，是的，32.当名称中包含大小时，实际考虑类型大小的可能性更大。使用Int32还可以提高其他选择的知识。当人们没有被迫至少意识到有其他选择时，int变得太容易成为“整数类型”了。

• 框架中旨在与32位整数进行交互的类称为Int32。再次，它是：更直观，减少混乱，缺乏一个（不必要的）翻译（而不是在系统中的翻译，但在开发商的头脑）等 int lMax = Int32.MaxValue或Int32 lMax = Int32.MaxValue？

• int不是所有.NET语言中的关键字。

• 尽管有人争论为什么它永远不会改变，但int不一定总是Int32。

缺点是要键入两个额外的字符和[bug]。

这不会编译

public enum MyEnum : Int32
{
    AEnum = 0
}

但这将：

public enum MyEnum : int
{
    AEnum = 0
}

你不在乎 您应该int大部分时间使用。它将有助于将来将程序移植到更广泛的体系结构（当前int是它的别名，System.Int32但可能会发生变化）。仅当变量的位宽很重要时（例如：要控制a的内存中的布局struct），才应使用int32和其他变量（以及关联的“ using System;”）。

int是System.Int32的C＃语言快捷方式

尽管这确实意味着Microsoft可以更改此映射，但有关FogCreek讨论的帖子指出[来源]

“在64位问题上–微软确实正在开发64位版本的.NET Framework，但我很确定int不会映射到该系统上的64位。

原因：

1. C＃ECMA标准专门指出int是32位，而long是64位。

2. Microsoft在Framework版本1.1中引入了其他属性和方法，这些属性和方法返回长值而不是int值，例如Array.GetLongLength和Array.GetLength。

因此，我可以肯定地说所有内置C＃类型都将保留其当前映射。”

int与System.Int32相同，并且在编译时将在CIL中变成相同的东西。

我们在C＃中按惯例使用int，因为C＃想要看起来像C和C ++（和Java），这就是我们在这里使用的...

顺便说一句，在声明各种Windows API函数的导入时，我确实使用了System.Int32。我不确定这是否是已定义的约定，但它提醒我要使用外部DLL ...

从前，int数据类型与编译器目标机器的寄存器大小挂钩。因此，例如，用于16位系统的编译器将使用16位整数。

但是，幸运的是，我们再也看不到16位了，当64位开始流行时，人们开始更加关注使其与较旧的软件兼容，而32位已经存在了很长时间，因此对于大多数编译器来说，int仅假定为32位。

我建议使用Microsoft的StyleCop。

它类似于FxCop，但是涉及样式相关的问题。默认配置与Microsoft的内部样式指南相匹配，但是可以为您的项目自定义。

可能需要一点时间来习惯，但绝对可以使您的代码更好。

您可以将其包括在构建过程中以自动检查违规情况。

int并且Int32是相同的。int是的别名Int32。

你不在乎 如果要考虑大小，我将使用byte，short，int和long。使用大于int32的int的唯一原因是，如果您需要一个大于2147483647或小于-2147483648的数字。

除了我不在乎之外，还有很多其他需要关注的项目。

在实践中没有什么区别，随着时间的流逝，您将采用自己的约定。我倾向于在分配类型时使用关键字，而在使用静态方法时使用类版本：

int total = Int32.Parse("1009");

int是的别名System.Int32，如下表所示： 内置类型表（C＃参考）

如果Microsoft将整数的默认实现更改为某些新的带版本版本（我们将其称为Int32b），则使用int。

然后，Microsoft可以将int别名更改为Int32b，并且我不必更改任何代码即可利用其新的（并有望得到改进）整数实现。

任何类型的关键字也是如此。

您无需关心大多数编程语言，除非您需要编写非常具体的数学函数或针对一种特定体系结构进行了优化的代码...只需确保类型的大小足以满足您的需要（如果您使用的是大于Int的类型，知道您将需要超过32位）

没关系 int是语言关键字，而Int32是其实际系统类型。

另请参见我在这里回答一个相关的问题。

使用Int或Int32都是一样的Int只是为了简化读者的代码而已。

使用Nullable变体Int吗？还是Int32？当您在包含null的字段上使用数据库时。这样可以避免许多运行时问题。

某些编译器在不同平台上具有不同的int大小（不是特定于C＃）

一些编码标准（MISRA C）要求使用的所有类型都必须指定大小（即Int32而不是int）。

为不同类型的变量指定前缀也很好（例如，b表示8位字节，w表示16位字，l表示32位长字=> Int32 lMyVariable）

您应该注意，因为它使您的代码更具可移植性和可维护性。

如果您将始终使用C＃，并且Portable C＃规范在这方面永远不会改变，则Portable可能不适用于C＃。

可维护的ihmo将始终适用，因为维护您代码的人员可能不了解此特定C＃规范，并且在int偶尔超过2147483647的情况下错过了一个错误。

在一个简单的for循环中，例如一年中的月份，您将不在乎，但是当您在变量可能会顺流的情况下使用变量时，您应该在意。

您还应该注意是否要对其进行按位操作。

使用Int32类型需要名称空间引用System或完全限定（System.Int32）。我倾向于int，因为它不需要导入名称空间，因此在某些情况下减少了名称空间冲突的机会。当编译为IL时，两者之间没有区别。

根据Visual Studio 2012中的即时窗口，Int32为int，Int64为long。这是输出：

sizeof(int)
4
sizeof(Int32)
4
sizeof(Int64)
8
Int32
int
    base {System.ValueType}: System.ValueType
    MaxValue: 2147483647
    MinValue: -2147483648
Int64
long
    base {System.ValueType}: System.ValueType
    MaxValue: 9223372036854775807
    MinValue: -9223372036854775808
int
int
    base {System.ValueType}: System.ValueType
    MaxValue: 2147483647
    MinValue: -2147483648

还要考虑Int16。如果您需要在应用程序的内存中存储一​​个Integer，并且担心使用的内存量，则可以使用Int16，因为它使用的内存较少，并且最小/最大范围比Int32小（这就是int ）

不久前，当我们拜访Microsoft .NET CLR产品团队中的某人时，我正在与Microsoft合作开展一个项目。这个人编写了示例代码，当他定义变量时，他使用了“ Int32”和“ int”以及“ String”和“ string”。

我还记得在Microsoft的其他示例代码中看到过这种样式。因此，我进行了一些研究，发现每个人都说“ Int32”和“ int”之间没有区别，除了语法着色。实际上，我发现很多材料建议您使用“ Int32”使代码更具可读性。因此，我采用了这种风格。

前几天，我确实发现了差异！编译器不允许您使用“ Int32”键入enum，但是当您使用“ int”时可以。不要问我为什么，因为我还不知道。

例：

public  enum MyEnum : Int32
{
    AEnum = 0
}

这可行。

public enum MyEnum : int
{
    AEnum = 0
}

摘自：Int32表示法与int