我应该使用int还是Int32
在C＃中，int和Int32是同一件事，但是我读过很多次，没有给出原因，int比Int32更受欢迎。有原因吗，我应该在乎吗？
解决方案
回答
你不在乎。如果要考虑大小，我将使用byte，short，int和long。使用大于int32的int的唯一原因是，如果我们需要一个大于2147483647或者小于-2147483648的数字。
除了我不在乎之外，还有很多其他需要关注的项目。
回答
我知道最佳实践是使用int，并且所有MSDN代码都使用int。但是，据我所知，除了标准化和一致性之外，没有其他理由。
回答
两者确实是同义词。 int看起来会更加熟悉，Int32使32位代码对那些阅读代码的人更加明确。我倾向于在只需要'integer'的情况下使用'int'，在大小很重要的地方使用'Int32'(加密代码，结构)，因此将来的维护者将知道在适当的情况下可以安全地放大int，请注意以相同的方式更改Int32.
生成的代码将是相同的：区别纯粹是可读性或者代码外观之一。
回答
int和Int32之间没有区别，但是由于int是许多人在风格上喜欢它的语言关键字(就像string与String一样)。
回答
int和Int32是相同的。 int是Int32的别名。
回答
以我的经验，这是很常规的事情。我不知道在Int32上使用int的任何技术原因，但这是：
- 打字更快。
- 对典型的C＃开发人员更熟悉。
- 默认的Visual Studio语法突出显示中的其他颜色。
我特别喜欢最后一个。 :)
回答
如前所述，int = Int32. 为了安全起见，在实现任何关心数据类型边界的内容时，请务必始终使用int.MinValue/int.MaxValue。假设.NET决定将" int"现在设为" Int64"，那么代码将更少地依赖于边界。
回答
int与System.Int32相同，并且在编译时将在CIL中变成相同的东西。
我们在Csince Cwants中按惯例使用int看起来像C和C ++(和Java)，这就是我们在这里使用的...
顺便说一句，当声明各种Windows API函数的导入时，我确实使用了System.Int32. 我不确定这是否是已定义的约定，但它使我想起我要使用外部DLL ...
回答
int可以容纳的字节数取决于编译的目的，因此，当我们为32位处理器编译程序时，它可以容纳2 ^ 32/2到-2 ^ 32/2 + 1的数字，而对于64位则可以保持从2 ^ 64/2到-2 ^ 64/2 + 1. int32将始终保存2 ^ 32个值。
编辑：忽略我的答案，我没有看到C＃。我的答案是针对C和C ++的。我从没用过C＃
回答
在实践中没有什么区别，随着时间的流逝，我们将采用自己的约定。在分配类型时，我倾向于使用关键字，而在使用静态方法时，我倾向于使用类版本：
int total = Int32.Parse(" 1009");
回答
我们无需关心大多数编程语言，除非我们需要编写非常特定的数学函数或者针对一种特定体系结构进行了优化的代码...只需确保类型的大小足以满足需要(如果我们需要使用大于Int的值，知道我们将需要超过32位)
回答
int是一个关键字，并且很明确。
在大多数情况下，这并不重要，但是有两点与Int32背道而驰：
- 我们需要一个"使用系统"；陈述。使用" int"不需要使用using语句。
- 可以定义自己的名为Int32的类(这很愚蠢且令人困惑)。 int始终表示int。
回答
没关系int是语言关键字，而Int32是其实际系统类型。
另请参阅我对相关问题的回答。
回答
从前，int数据类型与编译器目标机器的寄存器大小挂钩。因此，例如，用于16位系统的编译器将使用16位整数。
但是，幸运的是，我们再也看不到16位了，而当64位开始流行时，人们开始更加关注使其与较旧的软件兼容，而32位已经存在了很长时间，因此对于大多数编译器来说，int仅假定为32位。
回答
int是System.Int32语言的快捷方式
虽然这确实意味着Microsoft可以更改此映射，但有关FogCreek讨论的帖子指出[来源]
"在64位问题上-微软确实正在开发64位版本的.NET Framework，但我很确定int不会映射到该系统上的64位。
原因：
CECMA标准专门规定int是32位，而long是64位。
Microsoft在Framework 1.1版中引入了其他属性和方法，这些属性和方法返回长值而不是int值，例如Array.GetLongLength和Array.GetLength。
因此，我可以肯定地说所有内置Ctypes都将保留其当前映射。"
回答
ECMA-334：2006语言规范(p18)：
Each of the predefined types is shorthand for a system-provided type. For example, the keyword int refers to the struct System.Int32. As a matter of style, use of the keyword is favoured over use of the complete system type name.
回答
它们都声明了32位整数，并且正如其他张贴者所指出的那样，我们使用的大部分都是语法风格的问题。但是，它们的行为并不总是相同的。例如，Ccompiler不允许这样做：
public enum MyEnum : Int32
{
member1 = 0
}
但这将允许：
public enum MyEnum : int
{
member1 = 0
}
去搞清楚。
回答
如果Microsoft将整数的默认实现更改为某些新的带版本版本(我们将其称为Int32b)，则使用int。
然后，Microsoft可以将int别名更改为Int32b，并且我不必更改任何代码即可利用其新的(并有望改进)的整数实现。
任何类型的关键字也是如此。
回答
当我们只需要使用一种语言(对于不需要提醒自己有关数学溢出的代码)时，类型的字节大小就不太有趣了。变得有趣的部分是当我们在一种语言与另一种语言，Cto COM对象等之间进行桥接时，或者我们正在进行一些移位或者屏蔽时，我们需要提醒自己(以及代码审查合作伙伴)数据的大小。
在实践中，我通常使用Int32来提醒自己它们的大小，因为我确实写了托管C ++(例如桥接到C)以及非托管/本机C ++。
如我们所知，在Cis 64位中，但是在本机C ++中，它最终以32位结尾，或者char是unicode / 16位，而在C ++中是8位。但是我们怎么知道呢？答案是，因为我们已经在手册中查找了它，所以它是这样说的。
凭借时间和经验，当我们编写代码以在Cand其他语言之间架桥时，我们将开始更加认真地对待类型(这里有些读者在想"我们为什么？")，但是恕我直言，我认为这是一种更好的做法，因为不记得我上周编写的代码(或者我不必在我的API文档中指定"此参数是32位整数")。
在F中(尽管我从未使用过)，它们定义了int，int32和nativeint。将会出现相同的问题，"我使用哪个？"。正如其他人所提到的，在大多数情况下，这无关紧要(应该透明)。但我会选择int32和uint32只是为了消除歧义。
我猜这将取决于我们正在编码的应用程序，正在使用的应用程序，我们和团队遵循的编码实践等等，以证明何时使用Int32是合理的。
回答
如表中所定义，int是System.Int32的别名：
内置类型表(C参考)
回答
使用Int32类型需要名称空间对System的引用，或者是完全合格的System.Int32. 我倾向于" int"，因为它不需要导入名称空间，因此在某些情况下减少了名称空间冲突的机会。当编译为IL时，两者之间没有区别。
回答
还要考虑Int16. 如果我们需要在应用程序的内存中存储一个Integer并且担心使用的内存量，则可以使用Int16，因为它使用的内存较少，并且最小/最大范围比Int32小(这就是int )
回答
我总是使用系统类型，例如Int32而不是int。在阅读Applied .NET Framework编程作者Jeffrey Richter提出使用完整类型名称的很好案例之后，我采用了这种做法。这是我坚持的两点：
- 类型名称在.NET语言之间可能有所不同。例如，在C＃中，
long映射到System.Int64，而在具有托管扩展的C ++中，long映射到Int32. 由于在使用.NET时可以混合使用多种语言，因此可以确保无论读者喜欢哪种语言，使用显式类名始终会更加清晰。 - 许多框架方法都将类型名称作为其方法名称的一部分：
BinaryReader br = new BinaryReader(/ * ... * /);float val = br.ReadSingle(); //好，但是看起来有点奇怪...``Single val = br.ReadSingle(); //好，而且更容易阅读
回答
你不在乎大多数时候，我们应该使用int。它将有助于将来将程序移植到更广泛的体系结构(当前，" int"是" System.Int32"的别名，但可能会发生变化)。仅当变量的位宽很重要时(例如：要控制" struct"的内存中的布局)，才应使用" int32"和其他(与关联的" using System;"一起使用)。
回答
不久前，当我们拜访Microsoft .NET CLR产品团队中的某人时，我正在与Microsoft合作开展一个项目。这个人编写了示例代码，当他定义变量时，他使用了Int32 vs. int和String vs. string。
我记得在Microsoft的其他示例代码中看到过这种样式。因此，我进行了一些研究，发现每个人都说Int32和int之间没有区别，除了语法着色。实际上，我发现很多材料建议我们使用Int32来提高代码的可读性。因此，我采用了这种风格。
前几天，我确实发现了差异！编译器不允许我们使用Int32键入enum，但是当我们使用int时可以。不要问我为什么，因为我还不知道。
例子：
public enum MyEnum : Int32
{
AEnum = 0
}
这行得通。
public enum MyEnum : int
{
AEnum = 0
}
摘自：Int32表示法与int
回答
我记得Borland的旧时代和int不仅取决于计算机，还取决于编译器。因此，这里的重点是-如果我们是一个草率的编码器，则可以使用任何东西并继续使用这种方式。
如果我们担心内存管理，请考虑为什么Cis是一种强类型的语言，并且由于某种原因而拥有int32，int64和int16.
考虑一下：
for (int i=0; i<100; i++) { }
和
for (Int16 i=0; i<100; i++) { }
和
for (Int64 i=0; i<100; i++) { }
其中哪一个是最有效的？ Int16！我们可能会争辩说，在CIL中它们是相同的，但是如果我们将调用函数线程化了1000次呢？我们刚才浪费的内存已经是4kB(sic)。
实际的程序员会使用较小的名称，尽管它可能不会有所不同，因为在语义上它是更正确的，并且可能会在将来的编译中使用。其余的业余爱好者可以继续关心这些细节，因为我们不在乎这些细节，因此代码会很烂。就像自由植物。爱它！别草率！
回答
尽管它们(大多数)是相同的(请参见下面的一个[bug]区别)，但我们绝对应该注意并应该使用Int32.
- 16位整数的名称为Int16. 对于64位整数，它是Int64，对于32位整数，直观的选择是：int还是Int32？
- Int16，Int32或者Int64类型的变量的大小问题是自引用的，但是int类型的变量的大小问题是一个完全有效的问题，无论多么琐碎，都会使人分心，导致造成混乱，浪费时间，阻碍讨论等。(这个问题的存在证明了这一点)。
- 使用Int32可以使开发人员意识到他们选择的类型。一个int又有多大？哦，是的，32.当名称中包含大小时，实际考虑类型的大小的可能性会更大。使用Int32还可以提高其他选择的知识。当人们没有被迫至少认识到其他选择时，int太容易成为"整数类型"了。
- 旨在与32位整数进行交互的框架中的类称为Int32. 再次说明：更直观，更容易混淆，缺少(不必要的)翻译(不是系统中的翻译，而是开发人员的想法)，等等。 Int32.MaxValue`？
- int不是所有.NET语言中的关键字。
- 尽管有人争论为什么它永远不会改变，但int可能并不总是Int32.
缺点是要键入两个额外的字符和[bug]。
这不会编译
public enum MyEnum : Int32
{
AEnum = 0
}
但这将：
public enum MyEnum : int
{
AEnum = 0
}
回答
使用Int或者Int32都是一样的Int只是糖，可以简化读者的代码。
使用Nullable变体Int吗？还是Int32？当我们在包含null的字段上使用数据库时。这样可以避免许多运行时问题。
回答
某些编译器在不同平台上的int大小不同(不是C特定的)
某些编码标准(MISRA C)要求使用的所有类型均指定大小(即Int32而不是int)。
为不同类型的变量指定前缀也很好(例如b表示8位字节，w表示16位字，l表示32位长字=> Int32 lMyVariable)
我们应该注意，因为它使代码更具可移植性和可维护性。
如果我们始终要使用Cand，则Portable可能不适用于Cid，因此Cspecification在这方面永远不会改变。
可维护的ihmo将始终适用，因为维护代码的人员可能不了解此特定Cspecification，并且由于int偶尔超过2147483647而错过了一个错误。
在一个简单的for循环中，例如一年中的几个月，我们将不在乎，但是当我们在变量可能会出现逆流的情况下使用变量时，我们应该在意。
我们还应该注意是否要对其进行按位操作。
回答
在定义变量时，我总是使用别名类型(int，字符串等)，在访问静态方法时，我总是使用真实名称：
int x, y;
...
String.Format ("{0}x{1}", x, y);
看到类似int.TryParse()的东西看起来很丑。除了样式，我没有其他原因。
回答
我建议使用Microsoft的StyleCop。
它类似于FxCop，但用于与样式有关的问题。默认配置与Microsoft的内部样式指南相匹配，但是可以根据项目进行自定义。
可能需要一点时间来习惯，但绝对可以使代码更好。
我们可以将其包括在构建过程中以自动检查违规情况。
回答
最好不要使用int代替Int32，因为这样做有很多答案，但这是有充分理由的。 Int32始终为32位，在32x系统中int为32位，在64x系统中为64位。
