Лучшее имя для собственности?

Question

Какой из следующих трех вариантов вы выбрали бы для имени свойства в C# и почему?

1. YearToDateWages
2. YTDWages
3. YtdWages

Answer 1

Я хотел бы пойти с 1. Я предпочитаю не сокращать ничего, если только это не супер-общий акроним, который было бы смешно говорить. Что-то вроде «HyperTextTransferProtocolRequest» было бы смешно говорить, поэтому можно аббревиатура аббревиатура «HttpRequest». Это немного субъективно, но когда я сомневаюсь, я склонен не сокращать.

Если вы решили пойти с 2 или 3, я, вероятно, проголосую за 3, основываясь на рекомендациях из «Руководства по разработке рамок». В основном это говорит о том, что для сокращений, длина которых составляет 3 или более букв, вы должны использовать первую букву и нижний регистр для остальных. Это немного двусмысленно для двухбуквенных аббревиатур ... Некоторые люди предпочитают использовать все буквы типа «ID», а некоторые предпочитают использовать «Id». Руководящий принцип состоит в том, чтобы фактически использовать все буквы аббревиатуры с двумя буквами, но это противоречит руководящим принципам для акронимов с 3 + буквой, поэтому люди делают это в обоих направлениях.

Answer 2

Я думаю, что первый из них лучше, потому что это само описательный.

Answer 3

Я бы выбрал полное имя, а не одно с аббревиатурой. Это более описательно, и хотя «YTD» может быть очевидным для некоторых, это может быть не всем. YearToDate не слишком длинный, и смысл ясен.

Answer 4

Я бы использовал YearToDateWages, потому что, не будучи в списке, я не знал бы, о чем вы говорили.

Смотрите также general naming guidelines на MSDN:

В общем, вы не должны использовать сокращения или аббревиатуры. Они делают ваши имена менее читабельными. Точно так же трудно понять, когда можно с уверенностью предположить, что акроним широко признан.

Для правил капитализации аббревиатур см. Capitalization Conventions.

Не используйте сокращения или сокращения как части имен идентификаторов.

Например, используйте OnButtonClick, а не OnBtnClick.

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

Акцент в оригинале.

Answer 5

Microsoft предложила назвать правила конвенции из # 2

ничего с> 2 аббревиатурой буквы должны быть Xxx не XXX

но 2 должен быть XX

мне нравится меньше печатать, так что я пошел бы с YtdWages

Answer 6

зависит от цели.

Если вы делаете библиотеку, которая будет видеть внешнее использование, то .NET Framework Design Guidelines скажет, что # 1 является предпочтительным.

Если это внутреннее приложение/библиотека, то я рекомендую использовать формат, соответствующий стандарту разработки ваших команд.

Answer 7

Есть ли причина, по которой вы не использовали бы первый?

Это не только для других; если вам нужно что-то изменить в своем собственном коде 2 года спустя, хорошие, описательные имена помогут вам.

Answer 8

bool ShouldIUseAbbreviate(string abbreviate_) 
{ 
    foreach (var peer in myPeers) 
    { 
    if (!peer.CanGetTheMeaningWithinOneSecond(abbreviate_)) 
    { 
     return false; 
    } 
    } 

    return true; 
} 

Answer 9

. Структура .Net, похоже, в основном соответствует # 1. Поэтому я буду придерживаться этого. Сокращения следует избегать, за исключением случаев, когда они широко известны на уровне класса. Конечно, для локальных (функциональных) переменных это гораздо менее строгое, и я бы сказал, что сокращения и короткие имена гораздо более уместны, чтобы сделать код более компактным и более кратким.

Примеры хорошие аббревиатуры XML и HTTP. Кто серьезно собирается написать

string x=myobject.HyperTextMarkupLanguageOutput; 

Answer 10

Я голосую за номер 1.

Будет очень мало случаев, когда вы НЕ хотите описательного имени. Visual Studio поможет вам с длинными именами.

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