我应该使用int还是Int32

你不应该在意。如果大小是一个问题，我会使用字节，短，int，然后长。使用int型比int32大的唯一原因是需要一个大于2147483647或小于-2147483648的数。

除此之外，我不在乎，还有很多其他的事情需要关心。

我知道最好的做法是使用int，所有MSDN代码都使用int。然而，据我所知，除了标准化和一致性之外，没有其他原因。

这两者确实是同义的;int看起来会更熟悉一些，Int32使32位对那些阅读你的代码的人更明确。我倾向于在我只需要“整数”的地方使用int，在大小很重要的地方使用Int32(密码代码，结构)，这样未来的维护者就会知道，如果合适的话，扩大int是安全的，但应该注意以同样的方式改变Int32。

结果代码将是相同的:区别纯粹是可读性或代码外观。

int和Int32之间没有区别，但由于int是一个语言关键字，许多人在风格上更喜欢它(就像string和String一样)。

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

根据我的经验，这是一种惯例。我不知道在Int32上使用int的任何技术原因，但它是:

1. 打字更快。
2. 对于典型的c#开发人员来说更加熟悉。
3. 默认visual studio语法高亮显示的不同颜色。

我特别喜欢最后一个。：）

如前所述，int = Int32。为安全起见，在实现关心数据类型边界的任何内容时，请确保始终使用int.MinValue/int.MaxValue。假设. net决定int现在是Int64，那么你的代码就不那么依赖于边界了。

int与System相同。当编译时，它将变成CIL中相同的东西。

我们在c#中按照惯例使用int，因为c#希望看起来像C和c++(以及Java)，这就是我们在那里使用的……

顺便说一句，我最终使用的是系统。Int32时声明各种Windows API函数的导入。我不确定这是否是一个定义的约定，但它提醒我，我要去一个外部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");

你不应该关心大多数编程语言，除非你需要编写非常特定的数学函数，或者针对特定架构优化的代码……只要确保类型的大小对你来说足够(例如，如果你知道，你需要超过32位，则使用大于Int的类型)

int是一个c#关键字，是明确的。

大多数情况下，这并不重要，但有两件事与Int32相悖:

• 您需要有一个“using System;”语句。使用"int"不需要Using语句。
• 可以定义自己的名为Int32的类(这将是愚蠢和令人困惑的)。Int总是Int的意思。

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

另见有关问题的my 答案。

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

然而，谢天谢地，我们已经很少看到16位了，当64位开始流行时，人们更关心的是使它与旧软件兼容，32位已经存在了很长时间，以至于对于大多数编译器来说，int只是假设为32位。

int是c#语言中System的快捷方式。Int32

虽然这确实意味着微软可以改变这种映射，但在FogCreek的讨论中，一篇文章指出(来源)

“关于64位的问题——微软确实在开发64位版本的。net框架，但我很确定int不会在该系统上映射到64位。

原因:

1. c# ECMA标准明确规定int是32位，long是64位。

2. 微软引入了额外的属性&在框架1.1版中返回长值而不是int值的方法，例如Array。除了Array.GetLength之外的GetLongLength。

所以我认为可以肯定地说，所有内置的c#类型都将保持当前的映射。”

ecma - 334:2006 c#语言规范 (p18):

每个预定义类型都是系统提供类型的简写。例如，关键字int指向结构System.Int32。就风格而言，使用关键字优于使用完整的系统类型名。

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

public enum MyEnum : Int32
{
member1 = 0
}

但是它允许这样做:

public enum MyEnum : int
{
member1 = 0
}

图。

我使用int是为了防止Microsoft将整数的默认实现更改为一些新版本(我们称其为Int32b)。

然后，Microsoft可以将int别名更改为Int32b，我不需要更改任何代码就可以利用他们新的(希望是改进的)整数实现。

这同样适用于任何类型关键字。

当您只需要处理一种语言时，类型的字节大小就不太有趣了(对于那些不需要提醒自己数学溢出的代码)。有趣的部分是当你在一种语言和另一种语言之间建立桥梁，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。

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

还要考虑Int16。如果你需要在应用程序的内存中存储一个Integer类型，并且你关心使用的内存量，那么你可以使用Int16类型，因为它使用的内存更少，并且比Int32类型的最小/最大范围更小(这就是int类型)。

我总是使用系统类型——例如，Int32而不是int。我在阅读应用。net框架编程之后采用了这种做法——作者Jeffrey Richter为使用完整类型名提供了一个很好的例子。以下两点让我印象深刻:

1. 类型名可以在. net语言之间有所不同。例如，在c#中，long映射到System。在带有托管扩展的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。它将有助于将来将你的程序移植到更广泛的体系结构(目前int是System.Int32的别名，但这可能会改变)。只有当变量的位宽很重要时(例如:要控制struct在内存中的布局)，你才应该使用int32和其他变量(带有相关的"using System;")。

前一段时间，我在微软做一个项目，当时微软。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

虽然它们(大部分)是相同的(参见下面的一个[错误]差异)，但您绝对应该注意并应该使用Int32。

• 16位整数的名称是Int16。对于64位整数，它是Int64，而对于32位整数，直观的选择是:int或Int32?

• Int16、Int32或Int64类型变量的大小问题是自引用的，但int类型变量的大小问题是完全有效的问题，无论多么微不足道的问题，都会分散注意力，导致混乱，浪费时间，阻碍讨论等等(这个问题的存在证明了这一点)。

• 使用Int32可以使开发人员意识到他们对类型的选择。整数是多大来着?是的，32岁。当名称中包含类型大小时，实际考虑类型大小的可能性更大。使用Int32还可以提高对其他选择的了解。当人们不被迫至少承认有其他选择时，int就很容易变成“整型”。

• 框架中用于与32位整数交互的类名为Int32。再一次，这是:更直观，更少混乱，缺乏(不必要的)翻译(不是在系统中翻译，而是在开发人员的思想中翻译)，等等。

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

• 虽然有争论为什么它不太可能改变，但int可能并不总是Int32。

缺点是要多输入两个字符和[bug]。

这不会编译

public enum MyEnum : Int32
{
AEnum = 0
}

但这将:

public enum MyEnum : int
{
AEnum = 0
}

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

使用可空变量Int?还是Int32 ?当您在数据库中处理包含null的字段时。这将使您避免大量的运行时问题。

一些编译器在不同的平台上对int有不同的大小(不是c#特定的)

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

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

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

如果你总是要使用c#，而且c#规范在这方面永远不会改变，那么可移植可能不适用于c#。

可维护的ihmo将始终适用，因为维护代码的人可能不知道这个特定的c#规范，并且错过了int偶尔超过2147483647的错误。

在简单的for循环中，例如计算一年中的月份，您不会关心，但是当您在一个可能会owerflow的上下文中使用该变量时，您应该关心。

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

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

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

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

我建议使用微软的StyleCop。

它类似于FxCop，但用于与样式相关的问题。默认配置与微软的内部样式指南相匹配，但也可以根据您的项目进行定制。

它可能需要一些时间来适应，但它肯定会使您的代码更好。

您可以将它包含在构建过程中，以自动检查是否违反。

根据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

现在是2021年，我已经看完了所有的答案。大多数人说它基本上是一样的(它是一个别名)，或者，这取决于“你喜欢什么”，或者“按照惯例使用int”。没有答案会给你一个明确的当， 在哪里和为什么使用Int32而不是int。我就是为此而来的。

98%的情况下，你可以使用int，这是完全没问题的。另外的2%是什么吗?

有记录的IO(结构，本机类型，组织和压缩)。有人说无用的应用程序是可以读取和操作数据，但实际上不能写入新数据的应用程序到一个已定义的存储。但是为了不重新发明轮子，在某些时候，那些处理旧的数据的人必须检索关于如何读取它们的文档。而且它们很有可能是在long始终是一个32位整数. com的时代编译的。

以前也发生过这种情况，有些人很难记住db是一个字节，dw是一个单词，dd是一个双字，但这大约是多少位呢?在256-bits平台上的C# 43.0上的dw1…在那里(未来的)男孩们从未听说过“__abc12”。这是2%，其中Int32比int重要。MSDN今天说建议使用int是无关紧要的，它通常适用于当前的c#版本，但这可能会在未来的MSDN页面中被删除，在2028年或2034年?今天越来越少的人遇到WORD和DWORD，然而，二十年前，他们是常见的。在处理精确定长数据的情况下，同样的事情也会发生在int上。

在内存中，一个ushort (UInt16)可以是一个Decimal，只要它的小数部分是空的，它是正的或空的，并且不超过65535。但是在文件中，它必须是一个16位的short。当你阅读来自另一个时代的文件结构(在源代码中)的文档时，你会发现有3545个记录定义，其中一些嵌套在其他文件中，每条记录之间都有一对和数百块田地之间的不同类型。

在2028年的某个地方，一个男孩认为他可以按Ctrl-H-ing键离开 int到Int32，只有整词和匹配大小写……~67000个变化在整个解决方案。点击运行，仍然得到ctd。拍手拍手。想想哪一个int应该改为Int32，哪一个应该改为var。同样值得指出的是，当你处理tb级的数据时，Pointers是有用的(在某些云上有整个星球的虚拟表示，按需下载，并呈现到用户屏幕上)。指针在1%的情况下非常快，因为有很多数据需要实时计算，你必须使用不安全的代码进行交易。同样，这是提出一个实际有用的应用程序，而不是花时间移植到托管。所以，要小心，IntPtr已经是32位还是64位?您是否可以不关心读取/跳过多少字节的代码?或者直接(Int32*) int32Ptr = (Int32*) int64Ptr;…

一个更真实的例子是一个包含数据处理和它们各自的命令(源代码中的方法)的文件，就像内部分支(如果测试失败，则有条件继续或跳转到):

文件中的IfTest记录说:如果value等于someConstant，则跳转到address。其中address是一个16-bits整数，表示文件内部的一个相对指针(您可以返回到文件开头的32768字节，或再向下到32767字节)。但10年后，平台可以处理更大的文件和更大的数据，现在你有32-bits相对地址。你在源代码中的方法被命名为IfTestMethod(...)，现在你如何命名新的方法?IfTestMethodInt()还是IfTestMethod32() ?你也会重命名旧方法IfTestMethodShort()或IfTestMethod16()吗?然后十年后，你得到一个长(Int64)相对地址的新命令…那么10年后的128位命令呢?address0 !原则很好，但有时逻辑更好。

我或你写了一个代码今天，它对我们来说似乎没问题。它是在一个人的地方，试图理解我们写了什么，10年或20年后， 多少钱?及时(=钱)提出一个工作更新的代码?明确或写多余的注释实际上会节省时间。你喜欢哪一种?Int32 val;或var val; // 32-bits。

此外，使用国外数据来自其他平台或编译指令也是一个概念(今天涉及到Interop、COM、PInvoke……)这是一个概念我们无法摆脱，无论什么时代，因为它需要时间来更新(重新格式化)数据(通过序列化)升级dll到托管代码也需要时间。我们花了些时间把汇编程序抛在脑后，转而使用全c语言。我们正在花时间从32位数据转移到64位数据，然而，我们仍然需要关心8位和16位数据。未来会发生什么?从128位到256位还是直接到1024位?不要认为一个对你来说显式的关键字在20年后对阅读你的文档的人来说仍然是显式的(文档通常包含错误，主要是因为复制/粘贴)。

所以这里是:哪里使用Int32 <强>今天除以int ?

当你生产的代码是数据大小明智的 (IO，网络，跨平台数据…)，而在未来的某个时候——可能是几十年后——有人将不得不理解和移植你的代码。关键原因是基于时代的。1000行代码，可以使用int, 100000行，现在已经不是了。这是一个罕见的职责只有几个将不得不做，地狱，是的，他们有斗争，如果只是一些更明确一点，而不是依赖于"按照惯例"或“;它在IDE中看起来很漂亮，Int32太丑了"或“__abc7”，或“__abc8”，或“__abc9”;(是的，这就是这里一些评论的潜在含义)

不要把我写的作为一种普遍的看法，也不要试图在所有情况下推广Int32。我清楚地陈述了具体的情况(在我看来，这从其他答案中并不清楚)，以支持少数人被他们的主管指责写Int32很花哨，同时同一个主管不理解为什么要花这么长时间将C DLL重写为c#。这是一个边缘情况，但至少对于那些阅读“Int32"它的生命中至少有一个目的的人来说。

这一点可以通过将问题反过来进一步讨论:为什么不干脆在未来的c#规范中去掉__ABC0、Int64和所有其他变体呢?这意味着什么?