C# - StyleCop - SA1121：UseBuiltInTypeAlias - 可读性规则答案

【问题标题】：C# - StyleCop - SA1121: UseBuiltInTypeAlias - Readability RulesC# - StyleCop - SA1121：UseBuiltInTypeAlias - 可读性规则
【发布时间】：2011-08-25 10:10:45
【问题描述】：

在 SO 和 Google 上的 StyleCop 帮助手册中没有找到它，所以在这里 ;)

在 StyleCop 使用期间，我有一个警告：

SA1121 - UseBuiltInTypeAlias - 可读性规则

代码使用基本的 C# 之一类型，但不使用内置类型的别名。

而不是使用类型名称或完全限定的类型名称，这些类型的内置别名应始终使用：bool、byte、字符、十进制、双精度、短整型、长，对象，sbyte，浮点数，字符串， ushort，uint，ulong。

所以String.Empty 是错误的（取决于上述规则）而string.Empty 是好的。

为什么使用内置别名更好？ String. Int32、Int64（等）可以在特殊情况下使代码中的某些内容复杂化吗？

【问题讨论】：

我使用内置别名只是为了让我的代码在 Visual Studio 中更加丰富多彩。
线索就在名字里：Style Cop.这是风格问题。
@Richard，是的，阅读名称 Style COP。它应该代表一组每个人都可以同意的规则。我花了太多时间重新格式化边缘工程师的代码以使代码可读。这个行业需要一套单一的代码编写规则，而不是某种供人们“表达”自己的图画书。
@DRAirey1 格式化、命名并不是我们都同意永远的事情。因此，我之前的评论。你比我大（从你的个人资料来看），你肯定还记得关于 sytle 的分歧一直在持续吗？ “使代码可读”：建议：如果格式一致且不合理（例如，具有缩进以下结构），那么即使不是 my 样式，它也是可读的。关于命名的选择同样具有主观性。
@Richard。作为一个重要 IP 图书馆的雇主和所有者，我完全不同意。让 6 位不同的程序员按照 6 种不同的风格和命名约定编写代码并没有什么好处。反过来说，单一样式（例如样式 COP 的默认设置强制执行的样式）没有任何缺点。您唯一松懈的是围绕命名约定、匈牙利符号、属性顺序与方法等无休止的讨论。

标签： c# code-analysis rules stylecop

【解决方案1】：

一个类比可能会有所帮助：string 对于 System.String 就像 musket 对于步枪一样。 string 是旧语言的遗物，是为老程序员提供的。 C# 没有“内置”数据类型，这些别名是为这一概念有问题的一代“C”程序员提供的。

【讨论】：

【解决方案2】：

不那么混乱？对我来说，包含静态函数的基本数据类型（传统上只是一个值）似乎非常尴尬。如果您只是存储一个值，我理解使用等效的基本数据类型，但是对于访问类的成员，在基本类型名称之后放置一个 .(dot) 似乎非常尴尬。

【讨论】：

【解决方案3】：

澄清一下：并非所有人都同意 StyleCop 的作者。 Win32 和 .NET 大师 Jeffrey Richter 在他的优秀著作CLR via C# 中写道：

C# 语言规范指出，“就风格而言，优先使用关键字使用完整的系统类型名称。”我不同意语言规范；我更喜欢使用 FCL 类型名称并完全避免原始类型名称。其实我希望编译器甚至没有提供原始类型名称，并迫使开发人员使用 FCL 而是键入名称。以下是我的理由：
我看到许多开发人员感到困惑，不知道是否使用 string 或 String 在他们的代码中。因为在 C# 中 string （关键字）正好映射到 System.String（FCL 类型），没有区别，都可以使用。相似地，我听一些开发者说 int 在应用程序中代表一个 32 位整数在 32 位操作系统上运行，并且它在应用程序时表示一个 64 位整数在 64 位操作系统上运行。这句话是绝对错误的：在 C# 中，一个 int 总是映射 System.Int32，因此它表示一个 32 位整数，与操作系统无关代码正在运行。如果程序员会在他们的代码中使用 Int32，那么这种潜力也消除了混乱。

在 C# 中，long 映射到 System.Int64，但在不同的编程语言中，long 可以映射到 Int16 或 Int32。事实上，C++/CLI 确实将 long 视为 Int32。以一种语言阅读源代码的人很容易误解代码的如果他或她习惯于使用不同的编程语言进行编程，则意图。事实上，大多数语言甚至不会将 long 视为关键字，也不会编译代码使用它。
FCL 有许多将类型名称作为其方法名称一部分的方法。为了例如，BinaryReader 类型提供了诸如 ReadBoolean、ReadInt32、 ReadSingle 等，System.Convert 类型提供诸如 ToBoolean、ToInt32、ToSingle 等。尽管写以下内容是合法的代码，带有float的那一行我感觉很不自然，而且这行不是很明显正确：
BinaryReader br = new BinaryReader(...);
float val = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good
许多专门使用 C# 的程序员往往会忘记其他编程可以对 CLR 使用语言，因此，C#-isms 潜入类库代码。例如，微软的 FCL 几乎完全是用 C# 编写的，并且 FCL 团队的开发人员现在已经将方法引入到库中，例如 Array 的 GetLongLength，它返回一个 Int64 值，它在 C# 中是 long 但不是在其他语言中（如 C++/CLI）。另一个例子是 System.Linq.Enumerable 的 LongCount 方法。

【讨论】：

考虑使用块引用来表明确切是书中的引述，以及您的原始内容是什么。
@Cody Gray：随意编辑。我花了大约一个半小时打字并格式化文本。你看到的结果是我能想到的最好的结果。我在正文中明确指出，引用一直持续到答案结束。如果您认为可以改进这一点，请编辑答案。
@Cody Gray：我基本上不知道如何使用块引用，以便保留所有其余的格式（项目符号列表、代码突出显示等）。如果你可以给我看，我以后可以用。
啊，没问题。当您组合多个元素时，格式可能会有点混乱。我花了很多时间练习。混淆是“直到答案结束的一切”这句话。我不确定这是否意味着 all 其余部分，或者究竟是什么。并且 +1，因为我今天有更多的选票。 ;-)
@Cody Gray。给我报名。有没有什么地方可以向编写样式复制规则的人表达我们对此主题的强烈意见。我意识到我可以关闭它们，但需要更改这个。所有其他规则都很有意义，我不明白这个规则在那里做什么。保留旧数据类型的唯一原因是它们不会用完全陌生的东西吓跑 C++ 程序员。既然 C# 已经获得了（迄今为止）最佳编程语言的称号，他们需要放弃这种过时的做法。

【解决方案4】：

这条 StyleCop 规则假设使用别名不会给所谓的“普通语言用户”带来更少的混淆。例如，它知道 'long' 类型，但不知何故害怕 'System.Int64' 类型并且感到困惑然后看到它。就我个人而言，我认为在你的代码风格中保持一致很重要，不可能让每个人都满意。

【讨论】：

【解决方案5】：

因为内置别名是用该语言表达概念的更自然的方式。

有些文化说足球，有些文化说足球。哪个更合适取决于上下文。

【讨论】：

如果您仍然像“C”或 C++ 程序员一样思考，这只是“自然”。对于进化的程序员来说，“System.Boolean”和“MyLib.MyType”之间没有区别。 C# 平等对待所有数据类型。

【解决方案6】：

如果你有自己的String、Int32 等类型，最终可能会被使用而不是System.*，这只会使代码变得复杂——请不要这样做！

最终这是个人喜好。我在任何地方都使用别名，但我知道有些人（例如 Jeffrey Richter）建议不要使用它们。保持一致可能是个好主意，仅此而已。如果您不喜欢该 StyleCop 规则，请禁用它。

请注意，方法等的名称应使用框架名称而不是别名，以便与语言无关。这对于私有/内部成员来说并不是那么重要，但是对于私有方法，您可能也有与公共方法相同的规则。

【讨论】：

对于 .net 可能会或可能不会在 int 小于 32 位的情况下运行的怪异环境，不能以不同的方式定义别名吗？这是可能的，我认为这是使用别名的原因。
@the_drow：C# 规范明确将int 定义为global::System.Int32 的别名。因此，除非您考虑Int32 小于32 位的情况，否则任何兼容编译器都可以保证int 的大小。所以不，这与使用别名无关。更多的是为了熟悉，IMO...许多 C# 开发人员来自 int、char 等已经很常见的背景 - 诚然，它们可能与 C# 中的语义略有不同，但它们仍然很熟悉。
@JonSkeet：这个限制不会降低便携性吗？ Int32 可以小于 32 位吗？这没有多大意义。
“归根结底这是个人喜好”——我不能更强烈地反对。最终它是关于编码的标准。如果您想表达自己，请制作珠宝或精品香皂。如果您想成为一名工程师，请尝试创建标准代码。想象一下，如果汽车行业认为个人喜好是某些设计的理由？是的，我看到每个人都在使用 CAN，但我更喜欢令牌环。
@JonSkeet - 我再次恭敬地不同意。让客户（或您的雇主）带着您的所有工程师坐在会议室里几个小时试图弄清楚您的团队的“标准”将是什么，这对客户（或您的雇主）没有任何好处。您的股东在尝试挑选应遵守的规则时永远不会看到投资回报率。