Довольно простой вопрос: когда у меня есть устойчивый объект, он обычно имеет свойство ID (для абстрактных классов).
Итак, это идентификатор соглашения об именах или идентификатор?
например.
public int ID { get; set; }
или
public int ID { get; set; }
cheers:)
PS. Это для .NET btw. Конкурентом FXCop будет бонус.
Обычно я использую идентификатор. Если я действительно хочу сохранить его коротким (например, как часть более длинного идентификатора), я использую Id, если это не параметр или частный член.
. Принципы именования .NET Framework говорят следующее:
Акроним - это слово, которое формируется из букв слов в терминах или фразах. Например, HTML является аббревиатурой для языка гипертекстовой разметки. Вы должны включать аббревиатуры в идентификаторы только тогда, когда они широко известны и хорошо поняты. Сокращения отличаются от сокращений тем, что сокращение сокращает одно слово. Например, идентификатор является аббревиатурой для идентификатора. В общем случае имена библиотек не должны использовать сокращения.
Двумя аббревиатурами, которые могут использоваться в идентификаторах, являются ID и ОК. В идентификаторах с паскалем они должны отображаться как Id и Ok. При использовании в качестве первого слова в идентификаторе с верблюжьей линией они должны отображаться как id и ok соответственно.
Что бы вы ни хотели, просто будьте последовательны. ID не является словом, это аббревиатура идентичности. Как написать аббревиатуры - это то, о чем люди долго спорят. Например. это
getResourceURL
или
getResourceURL
фактически оба могут быть найдены в использовании в разных рамках. Другой популярный абб. с аналогичной проблемой является UTF8.
Просто важно быть последовательным, потому что в противном случае людям всегда нужно искать правильную капитализацию для каждого метода, если каждый метод обрабатывает его по-другому.
У меня для этого своя конвенция. Если абб. находится в конце имени, все капитализируется, если оно находится где-то в другом месте, оно соответствует правилам обозначения верблюда. Например.
getResourceURL
urlOfResource
compareUrlToString
Почему? Мне нравится abbr. капитализироваться. Большинство людей ожидают, что URL или UTF будут капитализированы. Однако, если посередине имени, оно разрушает преимущество верблюжьей нотации. Преимущество верблюжьего обозначения состоит в том, что вы видите, где начинается новое слово с помощью капитализации. Поэтому сравните:
compareURLToString
compareUrlToString
В первом случае я не вижу сразу, что URL - это одно слово, а To - следующее. T может быть частью URL (URLT) и быть другим аббревиатурой, поэтому я буду использовать вторую форму. Если это в конце, однако, это не будет играть роли, никакое другое слово не следует, поэтому я предпочитаю капитализированную форму. Я придерживаюсь этого соглашения во всем моем коде.
В рекомендациях указано "Id".
К счастью, ребята .Net были достаточно любезны, чтобы дать нам "правила именования", а не "законы об именах";), поэтому в основном, если вы решите, что нарушение правила правила добавляет больше ценности, чем после него, то все означает, что это нарушает его, никто не привлечет вас к ответственности за это, если они поймут ваши причины (например, он обеспечивает большую удобочитаемость и подчеркивает значение имени)
В моем магазине мы используем "ID", даже если в рекомендациях указано "Id", но никто не чувствует себя виноватым.
Как указывали другие, Id является правильным в соответствии с соглашениями .NET, но почему-то это не кажется правильным, поэтому многие люди используют ID (и все еще живут).
Я не знаю, каким будет содержимое вашего поля (числа, строки, подсказки), но если вы хотите пропустить проблему, вы можете просто использовать другое соглашение .NET для идентификаторов объектов: Имя
Мы используем ID внутри, потому что Id мне кажется, как говорят психологии, но FxCop жалуется, поскольку идентификатор не является аббревиатурой, его аббревиатурой (для Identity/Identifier). Согласно правилу FxCop разрешены только аббревиатуры, длина которых составляет два символа. Все остальное должно быть правильным.
Мы помещаем атрибут SuppressMessage в свойство ID, и все довольны.
"ИД" является одним из сокращений, закодированных в правилах именования FxCop, которые всегда считаются ошибочными, даже если они являются частью других слов. Единственный способ, которым я решил переопределить его, - это добавить "ID" в "Акронимы" как():
<Dictionary>
<Acronyms>
<CasingExceptions>
<Acronym>ID</Acronym>
</CasingExceptions>
</Acronyms>
</Dictionary>
Он работал с FxCop 1.36. Постскриптум В общем, я считаю, что "Id" - лучшая альтернатива, но иногда невозможно изменить имя, если оно сгенерировано на основе XML файлов (или веб-сервисов), которые мы не контролируем.
Я предпочитаю ID, также в сочетании с другими словами (например, CustomerID), но, строго говоря, это противоречит обычным соглашениям об именах.
Мы здесь видим вещи как "Id" или другие аббревиатуры в качестве слова, а "Id" - это просто, потому что в банковском бизнесе мы получаем много странных комбинаций букв. Поэтому мы рассматриваем это как слово, только с заглавной буквой, и то, как мы оказались в нашей внутренней документации по кодированию.
Но суть в следующем: выберите, что конвенция более удобна для команды разработчиков и других людей, которые смотрят на исходный код и придерживаются его.
http://en.wiktionary.org/wiki/id#Abbreviation
Зачем бороться с ним?