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

【问题标题】：How to avoid crazy naming conventions?如何避免疯狂的命名约定？
【发布时间】：2010-02-09 20:46:32
【问题描述】：

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

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);

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

欢迎任何反馈。

【问题讨论】：

标签： architecture naming-conventions recommendation-engine

【解决方案1】：

Pragmatic Programmers 普及了 DRY 原则：不要重复自己。这也适用于命名。一遍又一遍地重复相同的范围名称或前缀不会添加更多信息，只会使名称更长、可读性更低、更容易输入错误且更难搜索。如果你有 100 个以 PreferredLocation* 开头的类名，你将很难找到正确的类名:-(

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

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

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

如果是这样，您最好将PreferredTargetLocation 拆分为自己的类。这允许您编写：

List<PreferredTargetLocation>

而不是

List<PreferredTargetLocationPresenter.PreferredTargetLocation>

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

var locations = new List<PreferredTargetLocation>();

【讨论】：

presenter 就像一个经理，它有一个 PreferredTargetLocation 属性，在第一次使用 UI 实例化 Presenter 时加载。