Практичні міркування щодо конвенцій іменування HTML / CSS (синтаксис) [закрито]

Питання: які практичні міркування щодо синтаксису classта idзначень?

Зауважте, що я не запитую про семантику , тобто про фактичні слова, які використовуються, як, наприклад, описано в цьому пості . На цій стороні вже існує чимало ресурсів для іменування конвенцій, фактично затушовуючи мій пошук практичної інформації про різні синтаксичні біти: корпус, використання інтерпункту (конкретно -тире), конкретні символи для використання чи уникання тощо.

Підводячи підсумки, я задаю це питання:

• Називання обмеження по ідентифікатору і класу , природно , не призводить ні до яких конвенцій
• Велика кількість ресурсів на семантичній стороні іменних конвенцій незрозуміло шукає з синтаксичних міркувань
• Я не міг знайти жодного авторського джерела про це
• Про цю програму ще не було жодних питань щодо програмістів SE :)

Деякі з умов, які я розглядав, використовую:

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.) historical_incompatibility_plus_see: Документація Mozilla Dev .

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

Таким чином, це залишає ваші (1.) та (2.), UpperCamelCase та нижчіCamelCase відповідно. Незважаючи на ментальний зв’язок з класами Java (які, за чіткіше визначеною умовою, UpperCamelCase), назви класів CSS, мені здається, краще починати з малої літери. Можливо, це через імена елементів і атрибутів XHTML , але я думаю, ви також можете зробити так, що використання CSS-класів, що використовують UpperCamelCase, допоможе їх роз'єднати. Якщо вам потрібна інша причина, нижчийCamelCase - це те, що W3C використовує в прикладах для хороших імен класів (хоча сама URL-адреса, прикро, не погоджується зі мною).

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

Чи ви (чи хтось інший з цього питання) погоджуєтесь зі мною в цьому питанні, все-таки залежить від вас. Той факт, що ви досі не отримали однозначної відповіді, цитуючи авторитетні джерела, може сприймати як натяк на те, що в цьому питанні не існує такого поняття, як певний стандарт (інакше ми б усі цим користувались). Я не впевнений, що це обов'язково погано.

Слова у назвах класів CSS повинні бути розділені тире ( class-name), так як розділяються слова у властивостях CSS та псевдокласи , а їх синтаксис визначається специфікаціями CSS .

Слова в іменах ідентифікаторів також повинні бути розділені тире, щоб вони відповідали синтаксичному стилю імен класів, а імена ідентифікаторів becaus часто використовуються в 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для ідентифікаторів та класів, і не використовували його для будь-якої іншої конструкції чи цілі, ви б знали, що потрапили на кожен раз, коли бачили маркер у цьому форматі. Одне обмеження, яке це може накласти, це те, що воно було б найефективнішим, якби кожен ідентифікатор або клас мали 2+ слово, але це в багатьох випадках розумно.

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

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

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

Здається, ви не забули про один простий факт: більшість CSS не робиться програмістами .

Це роблять графічні дизайнери.

Вони не переймаються нашими війнами за редагування і не можуть менше дбати про те, що ми робимо з ключем "shift".
Вони навіть, мабуть, не знають, де цей фантазійний _ключ . (або як його звуть)

Їм не байдужа естетика коду , вони піклуються про естетику коду .

(І вони можуть мати крапку там)

Вони не читають специфікації , вони отримують підручник.
А потім двічі перевірте посилання на w3schools.

Деякі з них, напевно, вважають, що вони не можуть використовувати великі назви класів через причини.
Вони сповнені дивних, здебільшого нерелевантних помилок.