如何避免疯狂的命名约定？

Question

通常将程序集命名为一个名称，将程序集内的文件夹命名为另一个名称，然后 开始将这些名称带入这些文件夹内的类中？例如：

Project.Presenter
    Carriers
        CarriersFindPreferedCarriersPresenter.cs
        CarriersPreferencesPresenter.cs
        PreferredTargetLocationPresenter.cs

Project.Service.Fixture
    Carriers
        CarriersServiceFixture.cs

或者更进一步，甚至是这样的方法：

List<PreferredTargetLocationPresenter.PreferredTargetLocation> 
newlyAddedPreferredLocations = new
List<PreferredTargetLocationPresenter.PreferredTargetLocation>();

newlyAddedPreferredLocations.add(destinationLocation.PreferredCity);        

对我来说，随着您在项目上工作的时间越来越长并开始添加其他程序集和方法，这似乎变得越来越令人困惑。有更好的方法来处理这个问题吗？

欢迎任何反馈。

Answer 1

务实的程序员普及了 DRY 原则：不要重复自己。这也适用于命名。一次又一次重复相同的范围名称或前缀不会添加任何更多信息，只会使名称变得更长、可读性更差、更容易输入错误并且更难以搜索。如果您有 100 个以 PreferredLocation* 开头的类名，那么您将很难找到正确的一个:-(

所以我完全反对这一点。类和方法名称的范围由封闭路径决定/ 项目名称（在 java 中是 package，在 C# 中我不知道正确的术语是什么），所以如果您需要有关类/方法的下落的所有信息，就足够了看看它的完全限定名称。但是，在常规代码中，不应强制在任何地方都使用完全限定名称，唯一的例外是名称冲突，但我认为应该将其视为例外而不是规则。

此外，在设计良好的应用程序中，大多数方法/类不是全局可见的，仅在各自的包内可见（编程语言允许这样做 - Java 允许，我相信 C# 也是如此），这减少了名称冲突的风险。并进一步消除了对类名前缀的需要。

Answer 2

问一百个不同的人这个问题，你会得到一百个不同的答案。我喜欢任何使编写/维护代码最简单的方法，其中一半是长描述性名称，另一半是简短而甜蜜的名称。只要代码直观且灵活，我看不出任何一种方式有问题。

Answer 3

有时您必须使用较长的名称，但通常希望名称尽可能短。关键是要有描述性的名称，提供足够的细节，仅此而已。

Answer 4

PreferredTargetLocationPresenter.PreferredTargetLocation 是 PreferredTargetLocationPresenter 类型的子类型吗？换句话说，你是嵌套类吗？

如果是这样，您最好将 PreferredTargetLocation 分解到它自己的类中。这允许您编写：

List<PreferredTargetLocation>

而不是

List<PreferredTargetLocationPresenter.PreferredTargetLocation>

如果您在 C# 3.0 中工作，您可以使用 var 进一步缩短声明：

var locations = new List<PreferredTargetLocation>();