类的前缀/后缀答案

【问题标题】：Prefix/suffix for classes类的前缀/后缀
【发布时间】：2009-04-13 17:35:16
【问题描述】：

当您编写一个包含大量类的应用程序时，您是否对类名使用前缀/后缀？还是应该只依赖我已经定义的命名空间？

就我而言，我的课程如下：

Blur
Contrast
Sharpen
Invert
...

我只是不知道我明天可能有什么，并希望尽可能避免与 BCL 中常用的类发生冲突。

有什么想法吗？

【问题讨论】：

【解决方案1】：

命名空间正是为了解决这个问题而发明的。使用它们。

【讨论】：

【解决方案2】：

我想说不要在名称中使用前缀或后缀——这非常接近匈牙利表示法，这被广泛认为是不好的，即使是 MS 的创建者也是如此。该规则的唯一例外是接口，许多人认为可以使用I 作为前缀，但我认为接口也不应该有前缀。您应该将相关的类分组到命名空间中以防止冲突。

【讨论】：

+1 我确实喜欢在接口前加上 I 前缀，并且我经常对局部变量使用匈牙利符号，但实例级别或更高级别的任何内容都会获得“正确”的名称。
一篇关于发明者如何让 Joel Spolsky 使用匈牙利符号的 ihmo 优秀文章：joelonsoftware.com/articles/Wrong.html
I 前缀是我勉强采用的另一个痛苦的命名惯例。不幸的是，需要有一种清晰的方式来传达某物是一个接口。在 Java 中工作多年让我确信“I”前缀很痛苦，但总比没有好。
我已将 IDE 配置为以不同颜色（绿色和蓝色）显示接口和抽象类。不需要匈牙利人。我还对可变变量（紫色）进行了颜色编码，因此我不需要局部变量上的“final”关键字：img376.imageshack.us/img376/1856/mutableimmutablene2.png

【解决方案3】：

避免为类添加前缀或后缀，除非：

最后一个我很伤心。我不喜欢看到 Base 后缀，但是 API 的使用者很难知道他们无法根据名称实例化 Filter（不先尝试）。我不喜欢它，但这是我使用的约定。

编辑

根据 Jon B 的评论，自定义委托后缀为 Handler 很常见 (FilterExecutedHandler(object sender, FilterEventArgs e);)。虽然委托声明本身不是一个类，但它可能会导致名称冲突，所以应该在这里说明。

【讨论】：

【解决方案4】：

一般来说，我会将它们命名为描述性的名称（就像您所说的那样），但我会将它们分成适当命名的命名空间。

在你的情况下，我会举起类似

namespace AppName.ImageOperations
{
    public class Blur{...}
}

【讨论】：

【解决方案5】：

如果你有一个通用的基类或接口（例如类 Effect 或接口 IEffect），那么我可能会使用 Effect 作为这些类的后缀。

否则我倾向于使用命名空间。

【讨论】：

【解决方案6】：

在工作中，我们为所有类使用前缀，而一些类使用后缀。这确实阻止了 BCL 冲突，但我认为这是不必要的。最好使用合理的命名和良好的命名空间。

我建议对接口使用 I 前缀，但这只是个人喜好。

【讨论】：

【解决方案7】：

实际上，我不太关心前缀/后缀，而更关心命名空间分区和类名。我希望类名有意义，但我也需要正确的命名空间以避免冲突并统一我的公司代码库。

例如

namespace Company.Department.Product
{
     public class Class
     {}
}

这使得划分代码变得非常容易，并帮助程序员决定在哪里放置功能。设置需要更多时间，但我觉得最终它是值得的。

【讨论】：

【解决方案8】：

Guidelines for Names（来自 Microsoft）是一本有趣的读物……

对于命名空间，他们说：

命名空间名称的一般格式如下：

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

例如， Microsoft.WindowsMobile.DirectX

对于课程，他们会说一件事：

不要给类名加上前缀（例如作为字母 C)。

接口，应以字母 I 是一个例外这条规则。

值得至少浏览一下以获取一些想法...

【讨论】：