Я использую camelCase в своих именах полей кода и базы данных и т.д., но с полями, которые имеют Id в конце, он всегда становится трудночитаемым. Например, itemId, teacherId, unitId и т.д. В этих случаях я рассматриваю нарушение соглашения и запись itemID, teacherID, or unitID только для улучшения удобочитаемости.
Что вы делаете и какова общая, лучшая практика решения этой проблемы?
Я делаю то, что чувствую. В целом, ваша лучшая практика заключается в том, чтобы ошибиться в отношении читаемости и соответствия некоторым абстрактным стандартам.
Просто будьте последовательны.
Id - аббревиатура, а не аббревиатура, поэтому я делаю это "Id". UI - это аббревиатура, а аббревиатуры - короткие, в любом случае - получают заглавные буквы: "UI".
Вот пример того, что я делаю.
id
userId
getUserId
Ключ согласован.
Я действительно предпочитаю "ID". Но, как все говорят, согласованность - это самое главное.
Стив
Id, что касается идентификатора. Microsoft предложила, чтобы соглашения об именах указывали на то, что рекомендуемая практика и компиляция с анализом кода будут поддерживать это. Вы бы использовали идентификатор, если он стоял за два слова, начинающиеся соответственно с я и D, и вы действительно не должны использовать имена, начинающиеся с строчных букв, но в параметрах.
Это не имеет значения, до тех пор, пока вы будете соответствовать своей программе.
Говоря, я бы пошел с "Id".
Я также использую camelcase, и я также использую его, если имя заканчивается Id.
Id
Это мой субъективный ответ на субъективный вопрос.
Я отметил это как CW.
Я использую символы подчеркивания во всех именах моих таблиц, поэтому user_id. Даже если id является автономным, все строчные буквы.
Я собираюсь проголосовать здесь, но мне все равно!
он явно id. Идеи из глубины!
Я считаю, что читаемость имеет первостепенное значение и должна отменять вашу конвенцию, если она сделает ее намного проще для чтения. Я думаю, что минусы перевешивают плюсы за то, что вы придерживаетесь своего оружия/конвенции, если вы не можете его легко прочитать (насколько мы программисты ненавидят нарушать соглашения и протоколы).
В Machine SUIF Майк Смит и Гленн Холлоуэй жестко применяют конвенцию о том, что заглавная буква обозначает новое слово. Поэтому, хотя CPS - это аббревиатура transformToCps, а не transformToCps. Я обнаружил, что в конечном итоге их метод работает лучше, чем то, что мы сделали в Quick C--, где мы обычно делали все шапки для таких случаев, как ID и CPS.
FxCop/Code Analysis будет обозначать идентификатор как плохую аббревиатуру, поэтому, если вы хотите избежать отключения правила, вы можете согласовать и использовать Id по этой причине. Но опять же, это действительно не имеет значения, если вы последовательны, как было указано другими.
Независимо от того, что вам удобно, до тех пор, пока вы остаетесь в рамках своих собственных программ. (Если вы работаете в команде, вы должны следовать правилам команды или настроить некоторые).
Один момент, о котором не упоминалось, - важность получения хорошего шрифта. Это будет творить чудеса для вашей читаемости программы, и может быть, что проблема с контентом частично связана с проблемой шрифта:
Если вы не можете легко отличить Id от ld (Id and ld), вы должны изменить шрифт и, возможно, размер шрифта тоже. Лично я люблю Консола.
Я согласен с другими ответами, что самое главное - быть последовательным.
Я бы добавил, что если для вашей конкретной кодовой базы нет установленного стандарта, вы должны следовать соглашениям, установленным вашим языком или платформой. В Java аббревиатуры и другие заглавные слова некапитализированы для идентификаторов:
id
url
getId()
setUrlParameters()
В Objective-C это наоборот. У вас может быть строчная переменная "id" или "url", но у вас также есть такие классы, как:
NSURL
NSURLRequest
Итак, в Obj-C я бы выбрал имя метода, например:
setURLParameters:
Он произносил "глазное дело", а не "id как в id, эго и суперэго", поэтому ID, а не Id. Это мой голос, во всяком случае. Тот факт, что это аббревиатура, а не аббревиатура, не имеет значения, из-за того, как она произносится. Он произносился так, как если бы он был аббревиатурой, поэтому его также можно ввести так же. О, и случай верблюда - худшая идея в истории вычислений.:)
Идентификатор в столбцах базы данных и свойствах объекта. id в параметрах:
this.ID == id
Я предпочитаю использовать Id, и в нашей компании стандартом также является Id ID. Я не думаю, что есть проблема с использованием ID, если вам будет легче читать. Компилятору все равно:) Я использую одно и то же соглашение в столбцах Id моей схемы.
Различные языки имеют разные рекомендации. Для .NET вы можете читать Руководство по дизайну рамок: соглашения, идиомы и шаблоны для многоразовых библиотек .NET. Для Java вы можете читать Условные обозначения кода для языка программирования Java.
"Идентификатор" неоднозначен. Является ли это частью "эго" / "суперэго" модели человеческой психики? Вероятно, нет: вы, вероятно, пытаетесь сокращать слово, например "Идентификация" или "Идентификация" или "Идентификатор".
Избавьтесь от двусмысленности (и вопроса об корпусе), решив, что вы имеете в виду, а затем не сокращайте.