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

28

Вопрос: каковы практические соображения относительно синтаксиса в 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 для удобства чтения)

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

Йерун
источник
CamelCaseEverythingInCode
Ryathal
11
BUT_WHY_WOULD_YOU_DO_THAT_IS_THE_QUESTION? ;)
Jeroen
Я обычно строчные и CamelCase все остальное. Никаких особых причин
Антарр Берд
«css-style-classes, который согласуется с именованием свойств css (но может раздражать, когда Ctrl + Shift + ArrowKey выделение текста)» - это проблема, только если вы используете неоптимальный текстовый редактор ;-)
tdammers
@Ryathal, то есть PascalCase (или UpperCamelCase), camelCase (или lowerCamelCase) выглядит следующим образом.
Дэнни Варод

Ответы:

18

Награда или нет, в какой-то степени выбор всегда будет «вопросом предпочтения» - в конце концов, как бы вы себя чувствовали, если бы 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.) по причинам, указанным выше, но предположим, что аргументы могут быть сделаны для любого из трех других.

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

Амос М. Карпентер
источник
Благодарность! Вы упоминаете (как и большинство других ответов), что это вопрос предпочтений, но также дополняете его некоторыми практическими советами и несколькими хорошими ссылками на более важные соображения (такие как one_on_icompatability). Даже при том, что я все еще рассматриваю вопрос с предложением в ответе @tdammers (naming-with-dashes), ответ, данный здесь, является тем, который фактически отвечает на вопрос, который я задал. Итак: награда + принята, плюс большое спасибо :)
Jeroen
Большое спасибо назад - пока вы остаетесь последовательным, я думаю, что любой из этих трех в порядке. Между ними нет ничего особенного, и если вы посмотрите на сайты в сети, я уверен, что вы найдете множество примеров каждого из них ;-)
Амос М. Карпентер
+1 Хотя я уверен, что это обязательно плохо. Несмотря на то, что я полностью поддерживаю усилия сообщества по разработке стандартов именования, форматирования и общих стилевых соглашений, отсутствие единообразия может сделать наследование проекта кошмаром ( не говоря уже о том, что такой кошмар будет смягчен стандартами, они, вероятно, не будут затем ) Тот факт, что CSS, слабый и декларативный, настолько смешан с логикой приложения на стороне клиента и сервера, даже в виде простых хуков, он жаждет унифицированной структуры ( под этим тоской я имею в виду, я тоскую )
Дэн Лугг
Я определенно согласен с тем, что следует избегать подчеркивания (за исключением, возможно, идентификаторов, если ваш код на стороне сервера использует подчеркивания). Дефисы нельзя использовать в качестве разделителя в языках программирования, поскольку дефис также является оператором минус. Но в любом другом контексте, где вы могли бы использовать подчеркивание, я думаю, что дефисы являются более естественным выбором - их легче вводить и для URL-адресов, они более заметны, когда URL-адрес подчеркнут.
Мэтт Браун
7

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

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

Эмануил Русев
источник
Ах +1, мне нравится упоминание идентификаторов в URL. Хотя самое смешное, чтобы немного покопаться в этом, я пошел проверить, как это делает Википедия. Например, раздел поддержки Browswer в статье Wikipedia CSS дал <span id="Browser_support" class="mw-headline">Browser support</span>:: O
Jeroen
3

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

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

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

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

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

tdammers
источник
Спасибо за ответ! Я собираюсь увеличить награду, надеясь, что у кого-то есть ответ, который делает это менее «вопросом предпочтения». Если никто не появится, я обязательно приму ваш ответ.
Йерун
2

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

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

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

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

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

asfallows
источник
-1

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

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

Дуэйн Чаррингтон
источник
-3

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

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

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

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

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

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

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

Zjr
источник
3
Я думаю, это зависит от того, где вы работаете, я работал с дизайнерами, которые довольно воинственны в отношении стандартов; Судя по всему, вы привыкли работать с неопытными внешними разработчиками или дизайнерами печати, маскирующимися под веб-дизайнеров. Кроме того, я делаю разумное количество CSS в своих проектах, как и некоторые из моих коллег на работе, я думаю, что разделение дизайна / программирования действительно зависит от динамики компании.
Эд Джеймс