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

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

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

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

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

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

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

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

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. По этой причине мне не нужно использовать аббревиатуры.

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

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

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

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

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

  public interface IAccountReference
  {
    ...
  }
}

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

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

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

См. SRP для получения дополнительных сведений (извините, я тороплюсь ^^).