Подтвердить что ты не робот

Очень длинные имена классов

Я пытаюсь назвать класс (также члены, свойства и т.д.) как можно точнее. Но иногда я не уверен, что это так умно, если имя класса становится огромным (50 символов и более). Обработка настолько неудобна, и код становится трудночитаемым.

Вопрос возник для меня редко, и поэтому у меня нет большого опыта работы с такими длинными именами, но время от времени (сейчас) это происходит. Как другие люди справляются с этим? У вас есть приблизительный верхний предел, а затем делать сокращения или стоит ли боль обращаться с такими длинными именами?

Обновление

В качестве примера здесь приведен пример такого длинного имени класса.

ProjectContractChargingPeriodProjectAccountReferenceVM

Первый проект представляет собой домен, он может быть опущен, поскольку пространство имен подразумевает, что он обрабатывает проекты. Проблема в том, что если я делаю это с этим именем класса, то я должен сделать это со всеми классами этого пространства имен и что я окончательно не люблю, потому что тогда многие (короткие) имена классов этого пространства имен потеряют свою выразительность. [Project] ContractChargingPeriod описывает объект, для которого используется этот класс, и ProjectAccountReference означает, что класс является ссылкой на ProjectAccount. С ProjectAccount та же проблема, что и с ProjectContract. Использовать только учетную запись не имеет смысла, потому что в приложении есть и другие классы учетных записей. Ссылка немного слаба, потому что на самом деле ее немного больше, чем только ссылка, но это общая цель. VM - это аббревиатура, которую я всегда использую, и это означает ViewModel. Я думаю, что это законно, потому что каждый, кто работает с WPF, знает, что означает VM.

Я должен сказать, что класс используется для переноса класса из ORM, который построен со старым инструментом, который я создал давно. Классы там представляют квази 1:1 ERM, и я знаю, что это не оптимально, но изменение этого было бы большим усилием.

4b9b3361

Ответ 1

(Я использую Java/С++ и использовал другие языки OO, но не С#, то, что я говорю здесь, в значительной степени относится ко всем языкам, которые я использовал)

Я использую описательные имена классов. Я не думаю, что я сделал это до 50 символов, однако:-) Обычно имена длинного класса не являются общедоступными и обычно скрыты за интерфейсом и factory. Интерфейс имеет гораздо меньшее имя, чем классы.

Одна вещь, которую вы можете сделать, предполагает, что у вас есть несколько давно названных классов, которые тесно связаны, помещают их в пакет. Один из способов определить это - если все классы имеют одно и то же префиксное слово (ы). Если есть несколько классов, все из которых начинаются с одного и того же имени, то, возможно, вместо этого имя должно быть пакетом.

Ответ 2

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

Ни. Нет аббревиатур, кроме чрезвычайно хороших, таких как URL или HTTP. И, возможно, для локальных переменных с очень небольшим объемом. В противном случае подумайте о том, как получить имена, которые являются описательными и не очень длинными (я бы сказал, что более 30 символов слишком длинны).

Обычно длинные имена содержат избыточную или нерелевантную информацию, которая может быть исключена. Например, не помещайте там информацию, которая уже предоставляется из контекста (т.е. Информация в именах членов, которые уже присутствуют в имени класса). И избегайте неспецифических слов-заполнителей, таких как "данные", "информация", "обработчик", "менеджер", "помощник", "вычислить", "процессор" - они описывают практически весь код и поэтому не содержат реальной информации (и некоторые из них они отражают процессуальные концепции и являются почти запахом кода для этого).

Ответ 3

Как другие люди справляются с этим? У вас есть приблизительный верхний предел, а затем делать сокращения или стоит ли боль обращаться с такими длинными именами?

Предполагается, что класс должен представлять тип вещи: это существительное (а не глагол и, конечно, не целое предложение).

Мне нравится описывать мои вещи, используя одно или два слова, может быть три: только одно существительное или составное существительное (например, на немецком языке) или, возможно, прилагательное и существительное.

Например, здесь приведен список некоторых моих классов в одном проекте:

Ancestors.cs
Block.cs
BlockCollection.cs
BlockDocument.cs
BlockInline.cs
BlockInlineText.cs
BlockListBullet.cs
BlockListItem.cs
BlockP.cs
BlockSequence.cs
BlockTable.cs
BlockText.cs
BlockTextParent.cs
Border.cs
BorderEdges.cs
Box.cs
Canvass.cs
CaretLocation.cs
CaretLocationAndNode.cs
CaretLocationAndPoint.cs
CaretLocationData
CaretLocationPair.cs
CaretLocationPairAndPoint.cs
CaretsInBlock.cs
DebugDumpDom.cs
DebugOutput.cs
Display.cs
Displayed.cs
DocumentHandle.cs
DomDocument.cs
DomDocumentFragment.cs
DomElementBody
DomElementHandle.cs
DomElementTag.cs
DomEvent.cs
DomList.cs
DomNode.cs
DomNodeChild.cs
DomRange.cs
DomRangeBase.cs
DomTextBody.cs
DomTextHandle.cs
Edge.cs
Editing.cs
EditingState.cs
Editor.cs
EditorAction
EditorActions
EditorMutations.cs
EditorTransaction
EventListeners.cs
ExtractedRangeInDomDocument.cs
ExtraDebugInformation.cs
FormControl.cs
... etc ...

Как вы можете видеть, большинство имен классов - это всего два слова (составное существительное).

Я также использую пространства имен для разделения классов на разные категории и разные проекты (что помогает сократить имена классов короче: поскольку некоторая или большая часть иерархической информации находится в имени пространства имен, а не в имени класса).

Если мне повезло, тогда имена классов уникальны или почти уникальны после первых нескольких букв: поэтому, если я набираю первые несколько букв, я могу затем выбрать конкретный класс с помощью Intellisense. По этой причине мне не нужно использовать сокращения.

Ответ 4

Что касается примера ProjectContractChargingPeriodProjectAccountReferenceVM, вы можете реорганизовать его таким образом:

namespace Project
{
  public class ContractChargingPeriod implements IAccountReference
  {
    ...
  }

  public interface IAccountReference
  {
    ...
  }
}

ContractChargingPeriod имеет дело со всей бизнес-логикой, связанной с периодами зарядки контракта. Тот факт, что он реализует IAccountReference, также указывает, что объект относится к учетной записи, но без указания этого в имени класса.

Вы можете создавать простые viewmodels, которые отражают содержимое этих типов, но сами модели представления не должны содержать никакой бизнес-логики. Модели viewmodels могут использовать ту же структуру, что и приведенный выше пример, но должны быть определены в отдельном пространстве имен.

Ответ 5

Имя длинного класса может быть намеком на то, что ваш класс имеет много обязанностей (уведомление, которое я сказал "может" ).

Подробнее см. SRP (извините, я спешу ^^).

Ответ 6

50 символов нажимают на большой конец имен классов, но это немыслимо. Что касается Java, максимальный предел для полного имени класса (включая пакет) - 2 байта.

В дикой природе библиотеки Spring известны как имена длинного класса. Например, класс AbstractTransactionalDataSourceSpringContextTests находится под 49 символами. Это обеспечивает модульное тестирование с впрыском Spring beans (SpringContextTests); инжекция источника данных (DataSource); тесты являются транзакционными (Transactional); рассматриваемый класс является абстрактным (Abstract).

Попытка сжать это менее чем на 49 символов будет проблемой. Эта информация может быть предоставлена ​​в документации вместо этого, но для классов, которые используют/расширяют этот класс, который не будет сразу очевиден. Это может уменьшить понимание разработчиками, читающим ваши модульные тесты, поэтому здесь определенно есть компромисс, о котором вам придется подумать.

Ответ 7

Каждый раз, когда вы плохо себя чувствуете в своих длинных именах, попробуйте взглянуть на этот класс более 5 секунд. Я даю вам:

И его старшая сестра:

Не чувствуйте себя плохо, имена должны быть самоочевидными, поэтому, если ваше имя класса короче кода, содержащегося в нем, я думаю, что мы все хороши.