Практические соображения относительно соглашений об именах HTML / CSS (синтаксис) [закрыто]

Вопрос: каковы практические соображения относительно синтаксиса в classи idзначений?

Обратите внимание, что я не спрашиваю о семантике , то есть о фактических словах, которые используются, как, например, описано в этом посте . Уже есть много ресурсов по этой стороне соглашений об именах, фактически затеняя мой поиск практической информации о различных синтаксических битах: регистр, использование взаимодействия (в частности, -тире), конкретные символы, которые нужно использовать или избегать, и т. Д.

Подводя итог, я задаю этот вопрос:

• Ограничения именования для id и класса , естественно, не приводят к каким-либо соглашениям
• Обилие ресурсов на семантической стороне соглашений об именах затрудняет поиск синтаксических соображений.
• Я не мог найти авторитетный источник по этому
• По этой теме еще не было вопросов по SE Programmers :)

Некоторые из соглашений, которые я рассмотрел, используя:

1. UpperCamelCaseв основном как переходная привычка от серверного кодирования
2. lowerCamelCaseдля соответствия соглашениям об именах JavaScript
3. css-style-classes, что согласуется с именованием свойств CSS (но может раздражать при выделении текста с помощью Ctrl + Shift + ArrowKey)
4. with_under_scores, который я лично не видел, использовал много
5. alllowercase, легко запомнить, но может быть трудно читать для длинных имен
6. UPPERCASEFTW, как отличный способ раздражать ваших коллег-программистов (возможно, в сочетании с вариантом 4 для удобства чтения)

И, возможно, я также пропустил несколько важных опций или комбинаций. Итак: какие соображения существуют для соглашений об именах и к каким соглашениям они приводят?

Награда или нет, в какой-то степени выбор всегда будет «вопросом предпочтения» - в конце концов, как бы вы себя чувствовали, если бы W3C рекомендовал (или даже навязал) определенное соглашение, которое, по вашему мнению, не было правильным?

Сказав это, тем не менее, я лично предпочитаю lowerCamelCaseконвенцию, и я приведу причины и практические соображения, которые я использовал, чтобы принять решение - я сделаю это путем исключения, используя нумерацию из вашего вопроса:

(5.) только что легко читаемый, потому что не знаю, где слова начинаются.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTING.

(4.) history_incompatibility_plus_see: Документация по Mozilla Dev .

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

Таким образом, это оставляет ваши (1.) и (2.), UpperCamelCase и lowerCamelCase, соответственно. Несмотря на умственную связь с классами Java (которые, согласно более четко определенному соглашению, UpperCamelCase), имена классов CSS, как мне кажется, лучше начинать со строчной буквы. Возможно, это связано с именами элементов и атрибутов XHTML , но я полагаю, вы могли бы также доказать, что использование классов CSS с использованием UpperCamelCase поможет выделить их отдельно. Если вам нужна другая причина, lowerCamelCase - это то, что W3C использует в примерах для хороших имен классов (хотя сам URL, к сожалению, не согласен со мной).

Я бы посоветовал против (4.), (5.) и (6.) по причинам, указанным выше, но предположим, что аргументы могут быть сделаны для любого из трех других.

Согласны ли вы (или кто-либо еще в этом отношении) со мной по этому вопросу - решать только вам. Тот факт , что вы не получили определенное квотирование авторитетных источников теперь ответа может быть принят как намек , что не такая вещь , как определенный стандарт по этому вопросу (иначе мы все бы использовать его). Я не уверен, что это обязательно плохо.

Слова в именах классов CSS должны быть разделены с помощью dashes ( class-name), так как слова в свойствах CSS и псевдоклассах разделяются, и их синтаксис определяется спецификациями CSS .

Слова в именах идентификаторов также должны быть разделены дефисами, чтобы соответствовать синтаксическому стилю имен классов, поскольку имена идентификаторов часто используются в URL-адресах, а тире является исходным и наиболее распространенным разделителем слов в URL-адресах.

Это в основном вопрос предпочтений; не существует установленного стандарта, не говоря уже об авторитетном источнике, по этому вопросу. Используйте то, что вам наиболее удобно; просто будь последовательным.

Лично я использую css-style-with-dashes, но я стараюсь избегать имен классов, состоящих из нескольких слов, и использую несколько классов, где это возможно ( button important defaultскорее, чем button-important-default) По моему опыту, это также, кажется, самый популярный выбор среди высококачественных веб-сайтов и фреймворков.

Строчные буквы с тире также легче набирать, чем другие варианты (исключая трудно читаемое nowordseparatorswhatsoeverсоглашение), по крайней мере, на клавиатурах США, потому что для этого не требуется использовать клавишу Shift.

Для идентификаторов есть дополнительное практическое соображение, что если вы хотите ссылаться на элементы по их идентификатору непосредственно в javascript (например, document.forms[0].btn_ok), черточки не будут работать так хорошо, но тогда, если вы используете jQuery, вы, вероятно, собираетесь в $()любом случае используйте их , так что тогда вы можете просто иметь $('#btn-ok'), что делает этот пункт в основном спорным.

Для записи, другая конвенция я сталкиваюсь регулярно использует венгерские бородавки в идентификаторах , чтобы указать тип элемента, особенно для элементов управления формы - так что вы должны были бы #lblUsername, #tbUsername, #valUsernameдля имени пользователя этикетки, ввода и проверки подлинности.

Я твердо верю, что главное - это последовательность.

Есть два способа посмотреть на это:

1. Можно привести хороший аргумент alllowercaseили css-style-clauses(возможно, лучший выбор), потому что они будут наиболее согласованы с кодом, в котором они будут находиться. Это обеспечит более естественный поток кода в целом, и ничто не будет раздражать или неуместно ,

2. Не менее хороший аргумент может быть сделан для стиля, отличного от имен тегов HTML или предложений CSS, если он будет дифференцировать идентификаторы и классы таким образом, чтобы улучшить читаемость. Например, если вы использовали UpperCamelCaseидентификаторы и классы и не использовали его для какой-либо другой конструкции или цели, вы бы знали, что нажимаете на них каждый раз, когда видите токен в этом формате. Одно ограничение, которое это может наложить, состоит в том, что было бы наиболее эффективно, если бы каждый идентификатор или класс был именем из двух и более слов, но во многих случаях это разумно.

Записав этот ответ, я обнаружил, что гораздо более склонен ко второму выбору, но я оставлю оба, потому что думаю, что оба случая имеют свои достоинства.

Это все вопрос предпочтений или лени. CamelCasing легче набирать, но я предпочитаю использовать подчеркивание, поскольку лично мне легче читать и отлаживать, чем CamelCase. Не существует единого установленного соглашения о кодировании, я никогда не работал там, где были те же правила кодирования, что и до него.

У большинства компаний есть руководящие принципы, которые вы, как правило, должны соблюдать, чтобы сохранить код в чистоте и облегчить работу для всех. Если вы фрилансер, вы можете сделать все возможное, потому что вы единственный человек, работающий над кодом. На мой взгляд, есть только 2 соглашения о кодировании: CamelCase или Underscore нотация. Мой совет - выбрать один, а затем придерживаться его.

Вы, кажется, не замечаете одного простого факта: большинство CSS не делается программистами .

Это сделано графическими дизайнерами.

Они не заботятся о наших войнах редактирования и не заботятся о том, что мы делаем с помощью клавиши Shift.
Они даже не знают, где этот причудливый _ключ . (или как его зовут)

Они не заботятся об эстетике кода , они заботятся об эстетической эстетике .

(И они могут иметь точку там)

Они не читают спецификацию , они получают учебник.
А затем перепроверьте ссылки на w3schools.

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