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

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

Pragmatic Programmers 推广了 DRY 原则:不要重复自己。这也适用于命名。一次又一次地重复相同的作用域名称或前缀不会添加更多信息，只会使名称更长、可读性更差、更容易打错和更难搜索。如果你有 100 个以 PreferredLocation* 开头的类名，你将很难找到合适的一个:-(

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

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