.NET类前缀和后缀命名约定

Question

开发人员团队通常会根据类功能和模式中的角色来制定一些类命名约定。例如，我们使用以下后缀：

数据结构类的
• 信息（仅公共属性，没有方法，如业务实体）。
• Helper 用于整个项目中使用通用功能的类（StringHelper，FormatHelper，ImageHelper）
• 用于MVC控制器的控制器
• 存储库，用于包含按其专用实体（PersonRepository，OrderRepository）分组的操作的DAL类
业务逻辑类的
• 经理

等

您的团队使用的后缀/前缀的命名约定是什么？

Answer 1

我们使用了三个前缀：I，T和_。第一个用于接口，第二个用于泛型类型，第三个用于属性支持者。我强烈反对任何其他前缀。顺便说一句，这符合微软的建议。 编辑：我的意思是Microsoft建议不要使用I和T以外的前缀。见Guidelines for Names - Names of Classes, Structs, and Interfaces。我已经使用_进行了违规，但我觉得有必要区分私有字段和属性支持者，我喜欢_不是字母数字的事实。的 /修改

后缀列表实际上是无穷无尽的。它们通常基于基类/接口的名称，例如IDispatcher - ＆gt; EmailDispatcher。

就个人而言，我不太喜欢像Info这样的后缀，因为它们太通用了，因为大多数类都代表某种信息。最后，我喜欢使用Service作为后缀，而不是Manager。

修改 我经常使用Provider后缀，就像众所周知的ApplicationRoleProvider BCL类一样。

Answer 2

我们对接口使用'I'前缀，这就是它。一般来说，我们尝试遵守语言（我们使用多个）来命名约定，以避免在我们的代码中混合使用我们需要遵守现有约定的地方的约定。我们不会违反语言标准，因为这需要我们混合惯例。

在过去十年中，在处理了各种项目和编码标准之后，我开始相信越多的外来标准就会变得越来越多，它们对主观领域的影响越大，他们就越有可能完全拒绝人们阻碍了团队的工作效率。

有一些好的做法可以帮助使代码更容易调试，例如（不要在一行上填写多个语句，例如），并帮助生成更高效，更健壮的代码（在可以合理初始化时定义变量）范围有限），但那些没有非常公正，客观的支持他们的论点通常要求开发者订阅某人的个人偏好。

特别是对于命名惯例，某些做法只是彻头彻尾的有害而且适得其反。例如，当现代开发人员通常应该更多地关注类型提供的接口和多态性而不是特定类型本身时，匈牙利表示法主要关注类型。我也不是特别喜欢'经理'大会，因为大多数使用合成的高级课程通常被认为适合该类别，然后后缀变得非常多余并经常使用。

Answer 3

FXCop会识别前缀s_和m_，如果你混淆它们会抱怨。我比C＃开发人员更喜欢的通用_前缀更喜欢它们。

I始终用于接口，T用于通用参数。没有人对此提出异议。

其他所有内容都由像Collection这样的后缀处理。我不会列出它们，因为它们要么明显，要么特定于我公司的库。

我对控件的想法很复杂。有时我会使用正确的Pascal套装名称，有时我使用旧的VB风格的前缀，如txt，cmd，lbl等。两者都有mertis和缺陷。

Answer 4

对于类名，我更喜欢后缀到前缀;例如对于不同种类的Block类，我有BlockBase，BlockText，BlockCollection，BlockSequence，BlockTable，BlockDocument等。我更喜欢后缀，因为它有助于按字母顺序将它们组合在一起。

举另一个例子：如果我有几个实现IDispatcher的类，我可能更喜欢DispatchEmail而不是EMailDispatcher。

另一方面，我也可以使用内部命名空间（即项目/程序集中的文件夹）来执行此操作。

Answer 5

我们的团队为所有类添加了前缀'C'，所有接口都带有I，所有结构都带有T.这是可怕的 - 至少那些类以'C'开头。因为源文件与类具有相同的名称。然后，当按字母顺序列出源文件时，很难找到你想要的东西！ 由于该项目已有多年历史，因此无法重命名所有类和源文件，因此约定将保留。

Answer 6

你忘记了

• Model适用于MVC模型
• View获取MVC视图

我们也常常使用Manager用于在另一个类下进行某些控制的类，例如的UserManager。