Чи повинна змінна називатися Id чи ID? [зачинено]


126

Це трохи педантично, але я бачив, як деякі користуються Idяк:

private int userId;
public int getUserId();

та інші використовують:

private int userID;
public int getUserID();

Чи одна з них краща назва, ніж інша? Чому? Я бачив, що це робилося дуже непослідовно у великих проектах. Якби я встановив стандарт, з яким було б знайоме більшість людей? Який умовний стандарт?


40
Послідовність - це найважливіше, що має значення. Будь то кейс верблюда, або підкреслення чи що. Будьте послідовними.

38
Перегляньте API XML вашої мови, щоб побачити, як вони це роблять. Класи імен Java, такі як SAXParserі DOMException.NET XmlDocument. Виходячи з цього, я б сказав "ID" на Java, "Id" в C #.
luiscubal

1
Але ідентифікатори верхнього регістру, як правило, використовуються в Java для статичних полів, тому ім'я "ID" для базового поля не найкраще. І настає послідовність ...
Дунайський матрос

8
Ви б назвали змінні EGOта SuperEGO? Я так не думав. ;)
якийro

4
Що?! Послідовність? Де війна люті ?! Ось так, я цим призначу хранителя священного синтаксису полум'я верблюда, і цим розпорядженням, що робити це з усіма кришками для акріонімів, призначено для ноуб. Крім того, правильно бажати, щоб туалетний папір згортався зверху, якщо у вас немає котів, які нудьгують і роблять дивні речі, і в цьому випадку їм набагато важче розплутувати туалетний папір, щоб згортати знизу, що робить цю єресь прийнятною для власники котів. Я не знаю, чому я приймаю рішення про це. Думаю, Боб, що охороняє священне полум'я у напрямку туалетного рулону.
Ерік Реппен

Відповіді:


56

Найголовніше правило, яке слід дотримуватися в цих випадках, - це послідовність: Робіть так, як це роблять усі інші.

Наприклад, подивіться API XML вашої мови, щоб побачити, як вони це роблять.

Java називає класи, такі як SAXParser і DOMException , .NET імена класів, як XmlDocument .

Виходячи з цього, я б сказав "ID" на Java, "Id" в C #.

Однак я бачив, що Java EE 6 має анотацію з назвою @Id(див. Документацію ), тому здається, що Java вважає "Id" просто звичайним словом.


@Id вказує на ім'я класу анотацій, а не на ім'я змінної. Неправильний приклад.
jwenting

3
SAXParser може бути (і, на щастя, ні) SimpleAPIforXMLParser (або навіть SimpleApplicationProgramingInterfaceforExtesibleMarkupLanguageParser). Кожна велика літера є початком слова. Так що навіть у java має бути "Id"
user470365

2
@jwenting Проблема полягає у з'ясуванні, чи "id" вважається словом чи як двома словами. @Idговорить, що це одне слово, тому назва змінної буде "id".
luiscubal

Ні. SAX - це абревіатура, а Id - ні.
nalply

8
Ви маєте рацію використовувати IdC # (і .NET взагалі), але з іншої причини. Правило складається з великої літери всіх букв з абревіатурою з двох літер (наприклад IPAddress) і лише з великої літери першої літери довших абревіатур (як приклад, який XmlDocumentви подали). Але Idі Okє виключення з цього правила, конкретно згаданого. Повний короткий виклад див. У Capitalization Rules for Acronymsрозділі Capitalization Conventionsстатті. Але навіть Microsoft порушує це правило (наприклад, DbConnectionпроти DBNull)
Аллон Гуралнек

110

Послідовність - це цар; вибрати те чи інше, але робити це послідовно скрізь.

Однак, я вважаю за краще перший варіант, тому що він не порушує camelCase (це означає, що ви маєте пам’ятати два правила стилю, не лише одне).

Дві великі літери іноді використовується з - за цього , але ID дійсно просто форма Id-entification.


18
Мені б це не сподобалося, якби комп'ютерна програма намагалася отримати доступ до мого ідентифікатора.
Blrfl

1
userIdOfSender
Sean McSomething

19
@SeanMcSomething: Ick. SenderUserId
Роберт Харві

5
Хоча я погоджуюсь з вами, що "Id" - це кращий спосіб я бачити, де виникає плутанина: У щоденній розмові ми насправді кажемо це як би абревіатурою, як у "чи можу я побачити ваш посвідчення особи?"
500 - Внутрішня помилка сервера

3
Подивіться на інші абревіатури у справі верблюда. Там SoapProtocol, а не SOAPProtocol. ID короткий для документа, що посвідчує особу, тому я не розумію, чому до справи верблюда слід ставитись виключно. Втім, я вважаю за краще, щоб користувальницький користувач використовувався послідовно, ніж userId та userID, що використовувався непослідовно в моїй програмі.
Ніл

76

TL; DR: У контексті бібліотек класів .NET Microsoft рекомендує використовувати Id. Це трохи протиінтуїтивно, оскільки це рідкісний приклад абревіатури, дозволеної / рекомендованої (абревіатури, як правило, нахмурені).

Якщо ми говоримо про конвенції про бібліотеку класів C # або .NET, Microsoft має доступні досить чітко визначені рекомендації щодо імен . Вони добре продумані, мають багато пояснень з різних питань - насправді, кожен розробник повинен зайняти деякий час, щоб прочитати весь розділ Правил дизайну .

Що стосується акронімів , правило: це стосується двох буквених акронімів, ви схильні тримати їх у верхньому регістрі (де застосовано регістр Pascal), наприклад, IOStreamможе бути назва класу. Що стосується більш тривалої абревіатури, ви зменшуєте іншу частину абревіатури, наприклад, XmlDocumentабо HtmlParser. Це насправді є однозначним правилом (немає ніякої плутанини щодо того, де закінчується одне слово, і починається наступне, якщо ви не прикутуєте двобуквенні абревіатури), і ви дуже швидко звикаєте до нього.

Отже, це ID, чи Id? Ну, на думку Microsoft, це може бути не так, як ви думаєте:

Скорочення відрізняються від абревіатур тим, що абревіатура скорочує одне слово. Наприклад, ID - це абревіатура для ідентифікатора . Загалом, у назвах бібліотек не слід використовувати абревіатури.

Дві абревіатури, які можна використовувати в ідентифікаторах, - це ID та ОК. У ідентифікаторах, обкладених Pascal, вони повинні відображатися як Id та Ok. Якщо вони використовуються в якості першого слова в ідентифікаторі, який має вигляд верблюда, вони повинні відображатися відповідно id та ok.

Анекдотично, я фактично не впевнений, коли ця відмінність почала з’являтися в керівництві, але через кілька років (приблизно 3,0 / 3,5) загальна тенденція іменування в бібліотеках класів перейшла від ID до Id.


1
Це правило, якого я зазвичай дотримуюся. Оскільки id - це абревіатура, а не абревіатура, я завжди вважаю за краще використовувати "Id".
Тобі

Я використовую ID becuase, то він порушує конвенцію і виділяється як унікальний, і мені подобається іронія цього :)
RhysW

Я думаю, що Microsoft помиляються. Ідентифікатор є ініціалізмом для документа, що посвідчує особу, він не є коротким для посвідчення особи. (Педантично акроніми вимовляються.)
Том Хоутін - приклад

@ TomHawtin-tackline Ви робите цікавий момент, хоча я підозрюю, що це залежить від контексту. Щось на зразок властивості IDNumber на об'єкті Person мало б багато сенсу, але чи слід для VehicleId читати як "Документ про особу транспортного засобу" проти "Ідентифікатор транспортного засобу"? У контекстах програмування ідентифікатор - це досить поширене слово для всього, що однозначно ідентифікує екземпляр, і я можу стверджувати, що це більше застосовне тут.
Даніель Б

@DanielB У комп'ютерних мовах навіть SQL "ідентифікатор" зазвичай посилається на ім'я, наприклад, ім'я стовпця. Зазвичай він стає скороченим до "ident". Транспортний засіб - цікавий приклад, оскільки існують встановлені схеми VIN (Ідентифікаційні номери транспортних засобів). У типовому контексті програмування "документом" для сутності є число (це може бути навіть незабутньою можливістю).
Том Хотін - тайклін

15

Я прочитав дуже гарне пояснення в документі деяких конвенцій кодування. CamelCase завжди слід використовувати для абревіатур і скорочень, тому що легше розрізняти кордону слів (порівняйте XmlIdWriterз XMLIDWriter).


12
Ось ще краща ідея для розмежування меж слова: фактичні межі слів! xml_id_writer.
Каз

4
@Kaz Добре, да! Однак, CamelCase традиційно використовується в деяких мовах, і, здавалося б, недоречно використовувати підкреслення в таких ситуаціях. Як говорилося раніше, консистенція - це королівство.
gilden

1
Використання CamelCase лише тому, що основні бібліотеки деяких мов використовують це не послідовність, а скоріше відповідність.
Каз

3
@Kaz: У вас у магазині більше битв, ніж конвенції з кодами.
Роберт Харві

2

Як ми бачимо у функції за замовчуванням JavaScript getElementById (); Id написаний у випадку з верблюдом ...

Використовуйте "id", якщо використовується з підкресленням. Приклад: user_id

Використовуйте "Id", якщо називати вар без підкреслення, щоб розмежувати різні слова. Приклад: userId

Якщо його зміна однієї слова, вона повинна бути в повному регістрі, якщо в декількох словах var, тоді використовується нижній регістр верблюда. Приклад: thisIsExample

Але я настійно не рекомендую "ідентифікувати" всіх у CAPS, тому що ми зазвичай використовуємо всі обмеження для визначення КОНСТАНТІВ.


У третьому абзаці ваш приклад, здається, не відповідає вашому тексту?
ruakh

@ruakh thanx .. Виправлено ..
Сукрит Гупта

0

По-перше, абревіатура eschew.

По-друге, якщо абревіатура дуже відома, я рекомендую використовувати футляр верблюда.

Це тому, що вам не потрібно вважати сенс цього. просто трактуйте як звичайне слово

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.