Как избежать сумасшедших соглашений об именах?

Question

Общеизвестно ли имя сборки одному имени, назовите папку внутри сборки другой, а затем начните переносить эти имена в классы внутри этих папок? Например:

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

Project.Service.Fixture 
    Carriers 
     CarriersServiceFixture.cs 

Или нести этот futher, даже такие методы, как это:

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

newlyAddedPreferredLocations.add(destinationLocation.PreferredCity);   

Для меня это, кажется, становятся все более и более запутанной, как вы работаете над проектом дольше и начать добавлять дополнительные сборки и методы. Есть ли лучший способ работать с этим?

Любая обратная связь будет приветствоваться.

Answer 1

Pragmatic Programmers популяризировал принцип DRY: не повторяйте себя. Это относится и к именованию. Повторное использование одинаковых имен областей или префиксов снова и снова не добавляет больше информации, просто делает имена более длинными, менее читабельными, более легкомысленными и сложными для поиска. Если у вас есть 100 имен классов, начинающихся с PreferredLocation*, вам будет сложно найти правильный вариант :-(

Таким образом, я полностью против этого. Имена классов и методов ограничены вложенными названиями путей/проектов (в java, который будет package, в C# я не знаю, что такое правильный термин), поэтому, если вам нужна вся информация о местонахождении класса/метода, достаточно взглянуть на его полное имя. Однако, в обычном коде не нужно принуждать к использованию полного имени везде. Единственное исключение - столкновения имен, но я считаю, что это следует рассматривать как исключение, а не правило.

Кроме того, в хорошо продуманном приложении , большинство методов/классов не отображаются глобально, только insi их соответствующий пакет (где язык программирования позволяет это - 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>();