我应该使用int还是Int32

在C＃中， int和Int32是一样的东西，但是我读了很多次， int比Int32更Int32 ，没有任何理由。 有一个原因，我应该关心吗？

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

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

这两个确实是同义词。 int将会更加熟悉， Int32使32位对读取代码更加明确。 我会倾向于使用int ，我只是需要一个整数， Int32的大小是重要的（密码代码，结构），所以未来的维护人员会知道，如果适当的话放大一个int是安全的，但应该小心改变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”不需要使用语句。
  • 有可能定义你自己的Int32类（这将是愚蠢的和令人困惑的）。 int总是意味着int。

如前所述， int = Int32 。 为了安全起见，当实现任何关心数据类型边界的东西时，一定要使用int.MinValue / int.MaxValue 。 假设.NET决定int现在是Int64 ，那么你的代码就不那么依赖边界了。

int和Int32没有什么区别，但是因为int是一个语言关键字，所以很多人喜欢它的风格（就像string和String ）。

当你只需要处理一种语言时（对于不需要提醒自己数学溢出的代码），类型的字节大小并不是太有意思。 变得有趣的部分是当你在一种语言和另一种语言之间架起桥梁，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，但它是：

  1. 更快键入。
  2. 典型的C＃开发人员比较熟悉。
  3. 默认的visual studio语法突出显示中的不同颜色。

我特别喜欢最后一个。 🙂

我知道最好的做法是使用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。

缺点是两个额外的字符类型和[错误]。

这不会编译 

 public enum MyEnum : Int32 { AEnum = 0 }

但是这将会： 

 public enum MyEnum : int { AEnum = 0 }

你不应该在意。 大部分时间你应该使用int 。 这将有助于将您的程序移植到更广泛的架构（目前int是System.Int32的别名，但可以更改）。 只有当变量的位宽很重要（例如：控制一个struct内存中的布局）时，你应该使用int32和其他（和关联的“ using System; ”）。

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

虽然这确实意味着微软可以改变这种映射，FogCreek的讨论中的一个帖子指出[来源]

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

原因：

1. C＃ECMA标准特别指出int是32位，long是64位。

2. Microsoft在Framework 1.1版中引入了额外的属性和方法，它们返回long值而不是int值，比如Array.GetLongth和Array.GetLength。

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

int和System.Int32是一样的，在编译的时候它会在CIL中变成同样的东西。

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

顺便说一句，我最终使用System.Int32声明导入各种Windows API函数时。 我不知道这是否是一个定义的约定，但它提醒我，我要去一个外部DLL …

曾几何时，int数据类型与编译器所针对的机器的寄存器大小相挂钩。 所以，例如，一个16位系统的编译器会使用一个16位的整数。

然而，我们感谢不了多少16位，当64位开始流行时，人们更关心的是使它与旧的软件兼容，而32位已经存在了这么久，大多数编译器都是int只是假定为32位。

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

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

看起来像int.TryParse（）这样的东西似乎很难看。 除了风格之外我没有别的理由。

在实践中没有什么区别，你会采用自己的惯例。 我倾向于在分配类型时使用关键字，而在使用静态方法时使用类版本：

int total = Int32.Parse（“1009”）;

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

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

除此之外，我不在乎，还有很多其他的东西需要关注。

我建议使用微软的StyleCop 。

这就像FxCop ，但风格相关的问题。 默认配置与Microsoft的内部样式指南相匹配，但可以为您的项目定制。

这可能需要一点时间才能习惯，但它绝对会使你的代码更好。

您可以将其包含在构建过​​程中，以自动检查是否存在违规行为。

int是System.Int32的别名，如下表所示： Built-In Types Table（C＃Reference）

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

然后微软可以将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＃，C＃规范在这方面永远不会改变，那么C＃可能不适用于C＃。

可维护的ihmo将永远适用，因为维护你的代码的人可能不知道这个特定的C＃规范，并错过一个错误是int偶尔变得超过2147483647。

在一个简单的循环中，例如一年中的几个月，你不会在意，但是当你在可能的情况下使用变量的时候，你应该关心。

你也应该关心你是否要对它进行按位操作。

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

根据Visual Studio 2012中的立即窗口Int32是int，Int64很长。 这是输出： 

 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，因为它使用更少的memeory并且具有比Int32小的最小/最大范围（这是int 。）

前一段时间，当我们在微软.NET CLR产品团队的某个人的访问下，我正在和微软合作。 这个人编码的例子，当他定义他的变量，他使用“Int32”与“诠释”和“字符串”与“字符串”。

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

有一天我发现了一个区别！ 编译器不允许你使用“Int32”键入枚举，但是当你使用“int”的时候它会使用枚举。 不要问我为什么，因为我还不知道。

例： 

 public enum MyEnum : Int32 { AEnum = 0 }

这工作。 

 public enum MyEnum : int { AEnum = 0 }

取自： Int32 notation vs int

Interesting Posts