C# 中的类型/命名空间别名约定 [关闭]答案

【问题标题】：Type/Namespace alias conventions in C# [closed]C# 中的类型/命名空间别名约定 [关闭]
【发布时间】：2009-10-29 20:10:12
【问题描述】：

在 C# 中定义 namespace or type aliases 是否有任何既定的命名或编码约定？

对于那些不知道的人，C# 语言有一个特性，可以在文件的本地为命名空间和类型定义别名。当与第三方库发生命名冲突以及缩短代码中的类型名称时，这可能很有用。下面是它的外观示例。

using Forms = System.Windows.Forms;

我在网上看到的大多数示例都倾向于使用未缩写的大写名称作为别名，例如上面示例中的别名 Forms。在某些地方，包括 official MSDN page，它解释了名称空间 System.Collections 的别名为 colAlias 的示例。更复杂的是，有些人可能更喜欢根据定义的是命名空间别名还是类型别名来选择不同的准则。

为了说明我对别名指南感兴趣的原因，我将解释我在做什么。在最近的一个项目中，我开始简化一个模式，其中我有几个类继承自一个通用基类，该基类通过使用类型别名来接受复杂类型参数。

因此使用这种技术，一旦应用了类型别名，下面的复杂示例就会变得更具可读性。

public class MyClass: MyGenericBaseClass<TripleLindyFancyAlgorithm<List<SomeValueType>>, List<SomeValueType>>
{
    public override List<SomeValueType> DoSomething(TripleLindyFancyAlgorithm<List<SomeValueType>> operation)
    {
        // ...
    }
 }

下面是必须使用类型别名的更简洁的版本。

using Result = List<SomeValueType>;
using Algorithm = TripleLindyFancyAlgorithm<List<SomeValueType>>; // Note: cannot reference an alias within an alias definition!

public class MyClass: MyGenericBaseClass<Algorithm, Result>
{
    public override Result DoSomething(Algorithm operation)
    {
        // ...
    }
 }

虽然这看起来要简单得多，但很容易忘记像 Result 这样的别名实际上只是 List 的别名，并且没有称为 Result 的实际类型.为了在视觉上分离概念，我正在考虑遵循一些前缀约定，类似于在私有成员之前使用下划线“_”，以帮助区分类型别名和实际类型。不过，在我这样做之前，我想确保我没有重新发明轮子，因为可能已经有更成熟的约定了。

【问题讨论】：

标签： c# naming-conventions namespaces alias

【解决方案1】：

我只会在命名空间冲突的情况下使用别名（即只有当我不得不这样做时）。

至少对我来说，任何其他用途都只会让人感到困惑和分心。

【讨论】：

但是您必须承认，在我给出的示例中，如果您必须编写 100 多个类似的类，它们都具有相同的模式，那么类型别名功能确实会显着提高可读性。尽管我同意这可能会造成混淆，但我认为在这种类型的示例中，将复杂示例保留原样实际上会造成更大的混淆。
关于这个例子 - 嵌套泛型的深度几乎是不必要的，如果是这样，这表明应该重新设计类，而不是应该使用别名的标志。这对凡人来说太令人困惑了。
@Dave - 一个非常有效的观点，尽管要深入了解设计细节，我必须透露促使我提出这个问题的实际代码的细节。为了提高工作效率，我将尽量少关注示例的合理性以及是否应该使用类型别名，而更多地关注 C# 代码中类型别名的约定。

【解决方案2】：

命名空间别名不是大多数代码库的共同特性——我最后一次使用它时，高级开发人员对它并不熟悉，尽管已经使用 C# 多年。

由于它很少见，因此尚未为其制定约定。

我想说，如果您要使用别名，请与您的团队讨论以创建您自己的约定。

我看到使用别名的几种不同方式：

命名空间的首字母缩写词。通常是命名空间中的大写字母。
命名空间的最后 - 如果复数不复数。
描述性短名称。

【讨论】：

太好了，这真的是第一篇讨论约定的帖子，这是我最初提出这个问题的初衷。
获得赏金。感谢您解决所提出的问题（即不仅仅是陈述您自己的偏好）并以实际经验作为支持。
@MatthewStrawbridge - 谢谢。正如您所说，其他答案似乎根本没有解决这个问题，而是说明了个人偏好。答案的差异也表明，对于命名空间别名的约定确实没有达成共识……
我也接受了你的回答，原因与马修给出的相同。

【解决方案3】：

就我个人而言，我只会用它来保持智能感知的清洁。

using StringBuilder = System.Text.StringBuilder;

如果重命名类型，则会为维护程序员打开潘多拉魔盒。

【讨论】：

虽然我同意在没有保证的情况下使用这种技术对维护非常不利，但我认为没有任何改进的原始复杂示例可能更令人担忧。
我可能是疯了，但我认为当它如此明确时它更具可读性。
ChaosPandion，也许你是对的。然而，重点是讨论命名约定，尽管我认为考虑使用别名的编码指南很重要。

【解决方案4】：

命名空间别名最常见的两种情况是：

我看到并使用它（作为一种趋势）
我从另一种语言移植代码

对于第一种情况，不做评论。对于第二个，一个很好的例子是从 C 移植代码并使用命名空间别名来实现实用性，例如：

using i64 = System.Int64;
using u8 = System.Byte;
using u32 = System.UInt32;
using u64 = System.UInt64;

即使您将上述别名视为惰性编程，它们也有助于避免错误。

【讨论】：

您的代码示例不是命名空间别名，而是类型别名（均使用using 指令完成）。
对。就像“使用 StringBuilder = System.Text.StringBuilder;”来自 ChaosPandion。到目前为止，我的经验表明，大多数人都认为它是命名空间别名。
大多数人可能可以互换使用它们，如果他们使用它们的话。

【解决方案5】：

我认为那些倾向于不使用它们的人正在给出你所要求的答案。这是约定。这并不是说它没有用，但不使用它仍然是常态。

【讨论】：

公平评估，请考虑对某人的回答或我的原始问题发表评论。
为什么，虽然其他一些人反对使用 using，但没有人说这是对“在 C# 中定义命名空间或类型别名有任何既定的命名或编码约定吗？”这个问题的答案。我愿意:)
所以我猜你的答案是“否”，如果是这样，那将是一个简单且可以接受的答案。虽然很明显，从其他民族的 cmets 那里有一些约定，尽管可能不是很普遍或一致。
不，我的回答不是“没有约定”，而是“按照约定，积极避免”，这不太一样。
足够公平，可以购买并投票。

【解决方案6】：

您可以采用约定将它们用于抽象。

using Id = System.Int32;

这样您就可以轻松地将该行替换为

using Id = System.Guid;

在某些时候，无需更改其他代码（假设您没有通过抽象来创建对实际类型的依赖...）

【讨论】：

这适用于简单类型，但是一旦你有了一个类或泛型，就会有一些痛苦，因为这些方法很少在它们之间共享，除了非常一般的情况，例如 ToString()。不过，出于您列出的原因，我倾向于这样做。它实际上提高了可读性，以指定在使用它的上下文中有意义的类型。

【解决方案7】：

我一般只在需要在不同的命名空间中使用两个名称相似的类时才使用它们，并且不想在代码中完全指定类型：

using xItem = My.Project.NameSpace.Item;
using yItem = Your.ThirdParty.Framework.Item;

【讨论】：