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

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

Прагматичные Программисты популяризировали принцип СУХОЙ: не повторяйте себя. Это относится и к именованию. Повторное повторение одних и тех же имен областей или префиксов снова и снова не добавляет больше информации, а только делает имена длиннее, менее читабельными, их легче вводить неправильно и труднее искать. Если у вас есть 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>();