通用类文件名约定[关闭]答案

【问题标题】：Convention for Filenames of Generic Classes [closed]通用类文件名约定[关闭]
【发布时间】：2010-10-22 16:29:51
【问题描述】：

我希望能够区分类的通用版本和常规（非通用）版本。就像 .NET 框架对它的几个接口和集合类的通用和非通用版本所做的一样。 (Queue, Queue(T))

我通常喜欢遵循每个文件一个类的约定（如在 Java 中）。是否有命名包含单个泛型类的文件的通用约定？我对 Windows（特别是 NTFS）最感兴趣，但似乎一个好的约定（至少有点）可移植。

【问题讨论】：

你能举一个类的例子吗仅用于向后兼容。
“您能否举一个具有相同名称的特定类型和泛型类型的类的示例” - 您自己提供了一个答案：需要向后兼容的类库！

【解决方案1】：

我个人不会使用重音符号：

Foo.cs
Foo`1.cs

原因很简单，我害怕重音。它不仅有一个可怕的名字???，而且我不确定不同的文件系统、版本控制系统和 URL 将如何处理它。因此，我更愿意坚持使用常见的字母数字字符。

根据在 GitHub 上的搜索，NameOfT.cs 似乎用于 ASP.NET Core。 40 个结果。 Reference.

也用于 .NET Core 运行时。 36 个结果。 Reference.

例子：

Foo.cs
FooOfT.cs

【讨论】：

我更喜欢将`称为反引号，因此，它没有一个可怕的名字。

【解决方案2】：

有时我也会看到ClassName{T}.cs，但通常将其命名为ClassNameOfT.cs（就像微软之前提到的那样）

EntityFrameworkCore 项目（也是微软的）使用ClassName`.cs

【讨论】：

我不知道为什么这被否决了。这是官方 stylecop 分析器的默认设置。据我所知，stylecop 甚至不支持通用类文件名的方括号。

【解决方案3】：

我看到这个话题在一年多前就被放弃了，但我仍然想分享我对这个公约的看法。

首先，拥有多个具有相同名称但类型参数数量不同的类并不总是向后兼容的情况。当然，你不会经常看到它，但 .NET 的新 Action 和 Func 类就是这样设计的，我目前正在实现类似的东西。

为了清晰和可区分，我使用以下约定，仅指定给定类型的泛型参数的数量：

MyClass.cs
MyClass.T1.cs
MyClass.T2.cs

这样，我的文件名保持简短，同时仍然清楚地传达类名和不同数量的类型参数，但代价是一个简单的额外点（根据我的经验，这是在一个文件名，看起来比逗号和其他非字母数字字符好得多，但这只是我猜的口味问题）。输入类型参数的名称（或首字母缩写词）只会延长文件名，而在这个级别上，我对类型参数的实际名称并不感兴趣......

【讨论】：

+1，真的很喜欢！它简单、简短、足够清晰/信息丰富（在文件名级别），不应该引发太多的“符号恐惧症”。然而，作为一种变体，对于不需要多个点的情况，第一个点可以用下划线代替。或者对我来说就是这样：我对内部类使用多个点（除非它们少于~10行）。例如：MyClass.InnerClass.cs 或与泛型 MyClass_T2.InnerClass.cs 结合的示例。（我喜欢在内部类中使用点，因为它反映了它们在代码中的引用方式。）
在排序方面，这是唯一让我的强迫症满意的。
@AnorZaken 你是对的，但我认为下划线不是替换第一个点的最佳选择，因为下划线是类名中的有效字符（可能有一个名为“MyClass_T2”的类) 因此可能会产生冲突。也许是破折号/减号？？例如“MyClass-2.InnerClass.cs”

【解决方案4】：

如果您正在运行 Visual Studio 2008，请不要在通用文件名中使用重音符号 `。它们存在一个已知问题会导致断点失败：

http://connect.microsoft.com/VisualStudio/feedback/details/343042/grave-accent-in-filename-causes-failure-to-recognize-target-language-breakpoints-fail

【讨论】：

【解决方案5】：

在查找其他人对通用类文件名使用什么约定后发现了这个问题。

最近我一直在使用ClassName[T].cs。我真的很喜欢这个约定，我认为它优于其他约定，原因如下：

类型参数跳出来给你比他们做的多一点微软惯例（例如， ClassNameOfT.cs)。
它允许您拥有多个类型参数不要太多困惑：Dictionary[TKey, TValue].cs
它不需要您创建任何特殊文件夹，或将您的通用类放在一个特殊的命名空间中。如果您只有几个泛型类，那么为它们专门设置一个特殊的命名空间是不切实际的。

我从Boo 的通用语法中借用了这个约定，尽管稍作修改（Boo 使用ClassName[of T]）。

一些开发人员似乎对包含字母和下划线以外的任何内容的文件名有恐惧症，但一旦你能够克服这种约定，这种约定似乎就非常有效。

【讨论】：

当我第一次阅读这个约定时，我很喜欢它，但由于某些原因，当你有使用这种约定命名的文件时，某些扩展名（咳咳，CodeMaid）会吓坏，例如IFoo.cs 和IFoo[T].cs。当扩展程序运行以清理非通用文档时，它总是会影响通用文档...奇怪的行为。
我怀疑这种约定对于多平台项目可能会有问题。 IIRC，文件名中的[] 字符在类 UNIX 系统上具有特殊含义（类似于它们在正则表达式中的含义），因此在文件名中使用它们可能会迫使类 UNIX 系统上的用户转义文件名。

【解决方案6】：

在微软，他们使用ClassNameOfT.cs。

【讨论】：

这样，很清楚。虽然我可能仍会将该类命名为与非泛型版本相同的名称。
我想我想知道他们会如何做一本字典之类的东西。 DictionaryOfKT ?
在 ASP.NET MVC 1.0 源代码中，他们使用 Dictionary`2.cs 约定。
正如在其他地方提到的，在 Visual Studio 中存在已知问题，其名称包含重音符号的 C# 源文件。我认为这很不幸，因为它遵循通过反射命名它们的方式。
MyClass<TKey, TValue, TConversion, TCallback> -> MyClassOfTKeyOfTValueOfTConversionOfTCallback.cs?

【解决方案7】：

从目前的回复来看，似乎没有达成共识。

在子命名空间（和子文件夹）“Generics”（如 System.Collections.Generics）中使用相同的文件名是一个选项。但并不总是需要创建一个新的命名空间。

例如，在具有为向后兼容而维护但标有 ObsoleteAttribute 的非泛型类的现有命名空间中，最好将泛型版本保留在同一命名空间中。

我认为后缀是一种合理的方式。我采用了使用类型参数作为后缀的约定（因此：MyClassT 代表 MyClass，或 MyDictionaryKV 代表 MyDictionary。

【讨论】：

【解决方案8】：

我可能会将它们放在文件夹中并改用命名空间机制。您可以将 System.Collections 与 System.Collections.Generic 进行比较。另一方面，如果类使用泛型比不使用泛型更常见，也许最好指出那些不使用泛型的类。也就是说，如果您真的想将泛型类与其他类分开。就我个人而言，我通常不会费心去做，因为我并没有真正看到它有什么实际好处。

【讨论】：

【解决方案9】：

怎么样：

Type.cs

和

TypeGeneric.cs

每当我过去这样做时，我总是将这两种类型放在一个文件中，并以非泛型类型作为文件名。我认为这让事情变得非常清楚，因为 .NET 没有像 Java 那样对每个文件的一种类型进行约定/限制。

但如果你必须的话，我会建议像我上面所说的那样，使用后缀将使文件一起显示在任何按字母顺序排列的列表中（解决方案资源管理器、Windows 资源管理器等）。

这是另一个想法：

Type`1.cs

这将允许您通过它们接受的泛型类型参数的数量来划分不同的泛型类型。这只是一个想法，因为我仍然认为将所有类型放在一个文件中会更简单。

【讨论】：

【解决方案10】：

所有新的 Microsoft 类都使用泛型。 Queue 和 ArrayList 在泛型出现之前就已经存在。泛型是前进的方向。

一个类一个文件的约定是在类名之后命名文件名（无论是通用的还是非通用的）。对于 MyClass，您将拥有 MyClas.cs。对于每个新命名空间，您都需要创建一个新文件夹。这也是 Visual Studio 的工作原理。

【讨论】：

【解决方案11】：

我可能在项目中有两个文件夹，比如 Gereric、NonGeneric 或类似的东西。它们仍然可以在同一个命名空间中，然后它们都可以具有相同的文件名。只是一个想法......

【讨论】：

我个人尽量避免不同文件夹中相同命名空间中的类。我喜欢文件夹层次结构与命名空间层次结构相匹配，以造福于未来的开发人员。
很公平。无论如何，我可能会将它们放在单独的命名空间中。像 MyProj 之类的东西。和 MyProj.Generic。