为什么我们不为枚举，抽象类和结构添加前缀？

C＃社区已经无处不在地使用“ I”前缀来表示一个接口，即使是最没有经验的程序员也知道会使用它。

为什么我们不给枚举，抽象类或结构加上前缀（可能分别以“ E”，“ A”和“ S”开头）？

例如，如果我们确实用“ A”标记了所有抽象类，它将提供有关该类型的有价值的信息，尽管可以推断出这种信息并不是立即显而易见的。

请注意，我不主张这种改变，我只是在试图理解为什么我们不这样做。

该线程回答了我们为什么使用“ I”前缀的原因，但没有回答为什么我们不使用其他前缀的原因。

接口的命名约定的重点是，提供关于类调用的接口所要调用的内容的快速决策。如果您有一个Frobnicator，但必须声明一个用于解耦或任何原因的接口，则决定调用该接口IFrobnicator不需要任何有意识的思考，这很好。

相同的问题不适用于您命名的其他构造。枚举和结构很有用，但是除了名称本身之外，没有必要找到第二个简短的，透明的，明显相关的名称。因此，没有压力将“ E”打在枚举或结构的名称上。

（抽象类有点类似于接口，因为您必须提供第二个具体的类才能完成任何事情，因此抽象类可能已经获得了以“ A”开头的约定，但是由于某种原因，它们并没有这样做。我被允许推测，我认为“我是个特别狭窄的字母可能与此有关。）

我认为它使用不多，因为：

• 在大多数情况下，如果它是枚举，抽象类或结构并不会很重要
• 如果确实有用，我可能可以从使用情况中看到它，否则很快就会发现
• 如果我将其更改为枚举，抽象类或结构，则还必须重命名
• 对于不了解惯例的人来说，这纯属噪音。
• 人们可能只是不理会整个想法，因为他们被教导不要使用匈牙利符号。曾经有并且仍然有人说您不应该使用Hungarion表示法，而无需区分Apps Hungarian和Systems Hungarian。在这个SO问题中可以找到很好的讨论。不仅第一个答案很有趣，而且还有很棒的答案和评论。同样的问题来自Joel Spolsky的这篇文章（滚动至“我是匈牙利”段落）

简而言之：一般而言，增加值不会增加成本。

从最后一个要点和一些解释可以得出结论。系统匈牙利语（前缀类型）不好，不应使用。应用匈牙利语（前缀类型）。

回想一下您的问题，我认为您建议的符号表示形式是“ Apps Hungarian”，如果您认为增加的价值累加了成本，并且在代码库中始终如一地实现了它，那很好。但是由于您必须基于每个项目来考虑它，因此这不是一般规则。

我猜人们注意到它确实更经常地用于接口，这就是为什么它已成为接口的一般规则的原因。

只是（希望适用）一个想法：

有一个明显的趋势是“编码到接口”而不是具体的类。“现在”对于类的命名约定似乎更有益，例如以“ C”开头，而不是在接口上使用字母“ I”。

我刚刚结束了一个Java项目，在该项目中，所有接口实际上都称为Model。 ：

public interface SomethingModel{
}

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line
}

而在C＃中

public interface ISomething{}

public class SomethingModel : ISomething
{
   //i can read this
}

重新调动我的大脑以保持那种直觉的伤害，但是我可以看到思考接口编程方面的知识可能会有所帮助。