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

发布于 2024-11-06 20:08:48 字数 512 浏览 1 评论 0原文

在 StyleCop 帮助手册、SO 和 Google 上没有找到它，所以在这里；）

在使用 StyleCop 期间，我收到一条警告：

SA1121 - 使用BuiltInTypeAlias - 可读性规则
该代码使用基本的 C# 之一类型，但不使用内置的类型的别名。
而不是使用类型名称或完全限定类型名称，这些类型的内置别名应始终使用：bool、byte、字符、十进制、双精度、短整型、整数、长整型、对象、sbyte、浮点数、字符串、 ushort、uint、ulong。

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

为什么使用内置别名更好？可以字符串。 Int32、Int64（等等）在特殊情况下会使代码中的某些内容变得复杂？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

樱＆纷飞 2024-11-13 20:08:48

只是澄清一下：并不是每个人都同意 StyleCop 作者的观点。 Win32 和 .NET 大师 Jeffrey Richter 在他的优秀著作 CLR via C# 中写道：

C# 语言规范指出：“就风格而言，使用关键字优于使用关键字
使用完整的系统类型名称。”我不同意语言规范；我更喜欢
使用 FCL 类型名称并完全避免使用原始类型名称。事实上，我希望
编译器甚至不提供原始类型名称并迫使开发人员使用 FCL
请输入名称。以下是我的理由：
我见过许多开发人员感到困惑，不知道是否使用字符串
或代码中的字符串。因为在 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(...);
浮点数 = br.ReadSingle(); // 好的，但是感觉不自然
Single val = br.ReadSingle(); // 好的，感觉很好
许多专门使用 C# 的程序员往往会忘记其他编程
语言可以用来对抗 CLR，正因为如此，C# 主义逐渐渗透到了 CLR 中。
类库代码。例如，微软的 FCL 几乎完全是用 C# 编写的，
FCL 团队的开发人员现已将方法引入到库中，例如
Array 的 GetLongLength，返回一个 Int64 值，该值在 C# 中是 long，但不是
其他语言（如 C++/CLI）。另一个例子是System.Linq.Enumerable的
LongCount 方法。

Just to clarify: not everyone agrees with the authors of StyleCop. Win32 and .NET guru Jeffrey Richter writes in his excellent book CLR via C#:

The C# language specification states, “As a matter of style, use of the keyword is favored over
use of the complete system type name.” I disagree with the language specification; I prefer
to use the FCL type names and completely avoid the primitive type names. In fact, I wish that
compilers didn’t even offer the primitive type names and forced developers to use the FCL
type names instead. Here are my reasons:
I’ve seen a number of developers confused, not knowing whether to use string
or String in their code. Because in C# string (a keyword) maps exactly to
System.String (an FCL type), there is no difference and either can be used. Similarly,
I’ve heard some developers say that int represents a 32-bit integer when the application
is running on a 32-bit OS and that it represents a 64-bit integer when the application
is running on a 64-bit OS. This statement is absolutely false: in C#, an int always maps
to System.Int32, and therefore it represents a 32-bit integer regardless of the OS the
code is running on. If programmers would use Int32 in their code, then this potential
confusion is also eliminated.
In C#, long maps to System.Int64, but in a different programming language, long
could map to an Int16 or Int32. In fact, C++/CLI does treat long as an Int32.
Someone reading source code in one language could easily misinterpret the code’s
intention if he or she were used to programming in a different programming language.
In fact, most languages won’t even treat long as a keyword and won’t compile code
that uses it.
The FCL has many methods that have type names as part of their method names. For
example, the BinaryReader type offers methods such as ReadBoolean, ReadInt32,
ReadSingle, and so on, and the System.Convert type offers methods such as
ToBoolean, ToInt32, ToSingle, and so on. Although it’s legal to write the following
code, the line with float feels very unnatural to me, and it’s not obvious that the line is
correct:
BinaryReader br = new BinaryReader(...);
float val = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good
Many programmers that use C# exclusively tend to forget that other programming
languages can be used against the CLR, and because of this, C#-isms creep into the
class library code. For example, Microsoft’s FCL is almost exclusively written in C# and
developers on the FCL team have now introduced methods into the library such as
Array’s GetLongLength, which returns an Int64 value that is a long in C# but not
in other languages (like C++/CLI). Another example is System.Linq.Enumerable’s
LongCount method.