Повышение эффективности кодирования с соглашениями об именовании CSS

В frontend разработке написание чистого и эффективного кода делает программиста лучше. Неважно, идёт ли речь о личном проекте, совместном задании, agile-проекте или тестовом проекте при приёме на работу. Одним из основополагающих разделов, который обычно упускают из виду разработчики, является применение соглашений об именовании CSS, и некоторые из них на собственном опыте убедились в том, насколько страшен плохо написанный CSS-код при отладке и управлении огромными кодовыми базами. Независимо от того, осознаете вы это или нет, во время тестирования кодирования или технических собеседований ваши правила именования передают информацию о ваших методах разработки. Они могут быть использованы для оценки вашего поведения и эффективности. Итак, в этой статье мы расскажем о лучших практиках именования CSS, чтобы вы могли повысить качество своего кода. К концу статьи читатели должны чётко понимать соглашения об именовании CSS и их преимущества, а также будут знакомы с различными соглашениями об именовании стилей. Конечная цель статьи — дать читателям практические советы по использованию этих соглашений, которые они смогут применить в своей работе, чтобы писать более чистый и эффективный код.

Важность чистого и эффективного кодирования при frontend разработке

При работе над frontend частью веб-приложений, как правило, возникает множество требований к стилистике для улучшения привлекательности сайта и создания дружественного и интуитивно понятного пользовательского интерфейса. В процессе разработки существуют различные варианты построения компонентов и применения стилей к веб-странице: это может быть чистый CSS, использование CSS-фреймворка, например TailwindCSS или Bootstrap, или использование библиотеки компонентов пользовательского интерфейса, например Radix UI. Независимо от выбранного варианта разработки возникает необходимость сделать код легко читаемым и сопровождаемым. Это привело к появлению различных концепций в веб-разработке, таких, как компонентно-ориентированная разработка, обзоры кода, Agile-методологии и т.д. Разработка чистого кода является одной из таких практик и направлена на написание легко читаемого и сопровождаемого кода. Это достигается за счёт использования разумных имён, многоразовых компонентов, позволяющих избежать дублирования, и следования лучшим практикам. Соблюдение принципов чистого кода при написании кода может дать следующие преимущества для рабочего процесса приложения:

• Читабельность и понятность: Чистый код позволяет с первого взгляда понять назначение блоков кода. Это обеспечивает такой уровень понимания, который делает возможной работу с командой других разработчиков, поскольку тратится меньше времени на понимание смысла кода и его функциональности.
• Отладка и удобство сопровождения: В чистом коде присутствуют лаконичные блоки кода, модульные компоненты, меньше дублирования кода, осмысленные имена функций и переменных. Это позволяет легко отслеживать ошибки при их возникновении и вносить улучшения в код, добавляя новые возможности с меньшим риском появления ошибок в коде.
• Повторное использование кода: Чистый код усиливает необходимость модульности в процессе разработки. Этот принцип позволяет сделать код более организованным и коротким, поскольку модуль/компонент, необходимый для выполнения определённых задач, может быть импортирован, а необходимые параметры для выполнения задачи могут быть переданы компоненту для достижения желаемого результата. В этом случае разработчики используют существующие компоненты и функции при разработке различных частей приложения, что позволяет ускорить процесс разработки.
• Улучшение совместной работы: Грязная кодовая инфраструктура характеризуется отсутствием структуры и плохой читаемостью. Это затрудняет распространение работы над приложением на группу других разработчиков, поскольку требуется больше времени на их привлечение и совместную работу над кодовой базой. В случае чистого кода совместная работа становится возможной, и существуют чётко прописанные правила структурирования кода, обеспечивающие слаженную работу команды.
• Упрощение процесса подключения новых участников к текущим проектам: При наличии чистого кода новым участникам проще освоить проект. Чётко структурированные коды и логика, соответствующие установленным шаблонам и соглашениям, сокращают процесс адаптации, и новые участники могут быстро начать вносить свой вклад в проект, делая его в соответствии с установленными соглашениями.

Понимание соглашений об именовании CSS

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

Что такое соглашения об именовании CSS

Соглашения — это общепринятая практика, стандартизированное руководство по поведению, определяющее шаги, которым необходимо следовать при принятии решений или разработке проекта для конкретного случая использования. Важность общепринятых конвенций заключается в том, чтобы способствовать их пониманию большим количеством людей. Что же такое соглашение об именовании CSS? Под соглашениями об именовании CSS понимается набор общепризнанных рекомендаций и лучших практик, которые применяются при именовании классов и идентификаторов, используемых для стилей в коде CSS. Согласно этим рекомендациям, имена, присваиваемые классам и идентификаторам, должны быть последовательными и описательными, обеспечивающими определённую организацию или иерархию. Это делает CSS-код удобным для сопровождения и чтения без необходимости в многочисленных комментариях, поясняющих смысл стилевых блоков.

Преимущества использования хорошо определённых соглашений об именовании в кодовых базах

Использование чётко определённых соглашений об именовании классов/идентификаторов CSS даёт следующие преимущества для рабочего процесса:

• Согласованность кода: Соглашение об именовании определяет правила, которым необходимо следовать при присвоении имён свойствам CSS; это позволяет стандартизировать стиль именования и гарантировать, что все члены команды будут придерживаться одинакового подхода в процессе разработки, что позволит получить более профессиональный и согласованный результат.
• Читабельность и понятность: Соблюдение соглашений об именовании CSS позволяет разработчикам с первого взгляда определить назначение стилевого блока, его соответствующие компоненты в коде, а также форму его связи с дочерними, родительскими и родственными элементами. Это сокращает время, затрачиваемое на понимание структуры стилей в кодовой базе.
• Удобство поиска: Использование чётко определённых имён делает поиск и рефакторинг CSS-кода более эффективным и экономит время.
• Удобство поддержки и масштабируемость: При соблюдении соглашений об именовании элементов CSS их можно легко пересмотреть для внесения изменений или исправления ошибок. Новые функции или улучшения могут быть внесены в существующий код без появления ошибок.
• Сокращение количества багов и ошибок: С помощью соглашений об именовании можно объявлять классы, специфичные для определённых элементов и их свойств, что уменьшает количество ошибок в тех случаях, когда свойства CSS не имеют чётких названий, и разработчики могут неправильно использовать или неверно трактовать их назначение. Таким образом, использование соглашений об именовании CSS обеспечивает инфраструктуру для создания легко понимаемых, поддерживаемых и масштабируемых кодовых баз. Это способствует сотрудничеству, снижению количества ошибок и созданию устойчивой и здоровой архитектуры программного обеспечения.

Принципы именования CSS и лучшие практики

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

Руководящие принципы создания осмысленных и согласованных имён классов

• Лаконичность и связность: Названия, присваиваемые классам, должны быть максимально краткими и в то же время содержать необходимую информацию об их назначении. Избегайте использования слишком длинных имён, которые могут быть сложны для использования или чтения. Имена классов также должны быть согласованными, связывать элементы-близнецы или показывать отношения между родительскими и дочерними элементами.
• Избегайте чрезмерной вложенности: При присвоении имён классам следует придерживаться неглубокой схемы именования и не допускать чрезмерной вложенности селекторов. Это необходимо для повышения удобочитаемости и облегчения сопровождения кода.
• Последовательное именование: Выбор кейса для классов должен поддерживаться на протяжении всей разработки. В качестве примера можно привести kebab-case (обозначается строчными буквами и дефисами), camelCase (начальная буква — строчная, а в случае многословных слов первые буквы новых слов пишутся с заглавной буквы) и PascalCase (здесь все слова, составляющие имя, пишутся с заглавной буквы).
• Избегайте аббревиатур: Избегайте использования аббревиатур, за исключением случаев, когда эти аббревиатуры широко распространены и понятны. Это способствует ясности, позволяя с первого взгляда определить назначение названия класса. Популярными сокращениями являются btn для кнопок, nav для панелей навигации и cta для компонентов призыва к действию (call-to-action).
• Контекстное именование: Перед присвоением имён классам следует рассмотреть контекст, в котором будет использоваться элемент, и его возможности/функционал. Это позволяет выбрать наиболее подходящие имена для элементов и избежать конфликтов в процессе разработки.
• Последовательное присвоение имён в ходе разработки проекта: Перед началом разработки установите соглашение об именовании и рекомендации для проекта, чтобы все члены команды неуклонно следовали им для создания легко поддерживаемой и целостной кодовой базы.
• Избегайте общих или расплывчатых названий: Имена классов должны отражать замысел и смысл элемента, которому они присвоены. Это должно быть описательное имя, передающее его функции, чтобы облегчить поиск и понимание.

Лучшие практики структурирования CSS-кода

Для обеспечения организованности CSS-кода далее приведены лучшие практики/рекомендации, которых следует придерживаться в своей кодовой базе:

• Модульный подход: Код CSS, который может потребоваться несколько раз в процессе разработки для выполнения конкретной задачи, можно разбить на небольшие блоки кода многократного использования, чтобы избежать повторений.
• Соблюдайте соглашение об именовании: Включите в свой рабочий процесс соглашение об именовании CSS, которое поможет создать структурированные и описательные имена классов.
• Разделяйте структуру и представление: При организации CSS следует отделять стили, связанные с компоновкой и позиционированием элемента, от других стилей, описывающих его представление (стили, связанные с цветами, шрифтами, границами и т.д.). Например, можно определить класс-обёртку для стилей элемента max-width и его margin/padding.
• Ограничьте использование !important: Поведенческий модификатор !important навязывает строгое поведение элементу, к которому он применяется, и отменяет его изменения. Чрезмерное его использование может привести к конфликтам, затрудняющим обновление существующего стиля, поскольку свойство с модификатором !important приобретает приоритет.
• Используйте комментарии: Комментарии помогают создать контекст для блоков кода и могут использоваться для объяснения сложных участков или причин, по которым стилизация выполняется определённым образом. Это облегчает понимание написанного кода другими разработчиками.
• Последовательное форматирование: При структурировании кода следует использовать правильные отступы, интервалы и переносы строк для повышения удобочитаемости. Такие форматоры, как Prettier или Beautify, могут быть встроены в редактор кода для автоматического форматирования кода.
• Стили, связанные с группами: Блоки стилей, связанные с родственными элементами, должны быть помещены в таблицу стилей.
• Лаконичные CSS-селекторы: CSS-селекторы не должны быть слишком длинными или глубоко вложенными со сложными селекторами-потомками.
• Правильное именование селекторов: Селекторы должны быть названы в соответствии с элементами, к которым они применяются. Использование селекторов с неопределёнными именами приведёт к конфликтам, переопределению стилей и нежелательному поведению.
• Избегайте использования ID для стилизации: Использование идентификаторов для применения стилей может вызвать проблемы при попытке изменить стили данного компонента. Для облегчения сопровождения кода лучше использовать идентификаторы как средство уникальной идентификации при стилизации с помощью классов CSS.

Практические примеры использования соглашений об именовании CSS

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

БЭМ

БЭМ (блок, элемент, модификатор): БЭМ — это популярное соглашение об именовании CSS, разработанное российской технологической компанией "Яндекс" для обеспечения модульного подхода к CSS-стилистике, многократного использования кода и поддержки крупномасштабных CSS. БЭМ — это аббревиатура от Блок, Элемент и Модификатор, которые представляют собой следующие принципы:

• Блок: Блоки — это самостоятельные компоненты, которые могут создаваться в процессе разработки. Обычно это элементы родительского/верхнего уровня, которые могут оборачиваться вокруг дочерних элементов. Блоки обозначаются с использованием строчных букв и дефисов. Например, .nav, .header, .carousel, .card и т.д.

• Элемент: Элемент — это часть блока, которая не может существовать самостоятельно, поскольку её определение зависит от родительского блока. Он представляет собой дочерний блок, для обозначения связи с которым используется двойное подчёркивание (__). Предположим, что мы создаём компонент карточки с элементами title, description и image. В приведённом ниже блоке кода показано применение БЭМ для именования классов этих элементов:

  /* Родительский элемент card */
  .card {
  /* стили родительского компонента*/
  }
  /* Дочерние элементы: title, description, image */
  .card__title {
  /* стили заголовка */
  }
  .card__description {
  /* стили описания */
  }
  .card__image {
  /* стили изображения */
  }

• Модификатор: Модификаторы означают изменение состояния блока или элемента и обозначаются префиксом в виде двойного дефиса (--). Модификаторы добавляются к имени блока или элемента, представляя собой его разновидность. Примером модификатора является --active, обозначающий активное состояние элемента/блока. В приведённом ниже блоке кода показано добавление модификаторов к блоку карты, определённому выше:

  /* Модификатор для тёмного режима */
  .card--dark{
    /* стили для родительского компонента в тёмном режиме */
  }
  .card__title--dark {
    /* стили для заголовка в тёмном режиме */
  }

Цель БЭМ — сделать имена классов легко идентифицируемыми с первого взгляда, а также определить, где может использоваться элемент и как он связан с другими элементами. Используя БЭМ, мы также можем указывать, когда элемент является потомком определённого класса, при написании стилей в CSS. Предположим, что класс title является потомком другого класса card, мы можем оформить это так, как показано в приведённом ниже блоке кода:

.card {
 /* Стили для блока card */
 &__title {
  /* Стили для элемента title внутри блока card */
 }
}

Префиксы пространства имён

Использование префиксов пространства имён — это соглашение об именовании, которое подразумевает добавление определённого префикса к именам классов для передачи информации об их назначении и использовании в проекте. Это позволяет создать контекст для имён классов и избежать конфликтов именования, поскольку префиксы уникальны по сравнению с другими классами, даже если они имеют схожие имена. Пример реализации использования префиксов пространства имён показан в приведённом ниже блоке кода:

/* Стилизация кнопок cta разделов главной страницы и страницы "О нас" */
.home .cta-button {
 background-color: blanchedalmond;
}
.aboutUs .cta-button {
 background-color: yellow;
}

Предположим, что у нас есть две кнопки cta на главной странице; это можно решить следующим образом:

<!-- HTML structure -->
<div class="home">
 <button class="cta-a-button">Button A</button>
 <button class="cta-b-button">Button B</button>
</div>

И для CSS:

/* CSS с префиксами пространств имён */
.home .cta-a-button {
 background-color: blanchedalmond;
}
.home .cta-b-button {
 background-color: yellow;
}

Atomic CSS

Atomic CSS — это строительный блок, реализованный в большинстве современных библиотек CSS, например, в TailwindCSS. Он предполагает определение небольших блоков одноцелевых классов многократного использования, применяющие определённый стиль или свойство к элементу, к которому они прикреплены. Примеры блоков кода Atomic CSS показаны ниже:

/* Atomic CSS для отзывчивых контейнеров */
.container {
 width: 100%;
 max-width: 1280px;
 margin: 0 auto;
}
.container-sm {
 max-width: 768px;
}
/* Atomic CSS классы свойств */
.mt-2 {
 margin-top: 8px;
}
.px-2 {
 padding-left: 8px;
 padding-right: 8px;
}

Затем эти определённые классы могут быть применены к требуемым элементам:

<div class="container px-2"></div>

Atomic CSS также позволяет использовать определённое сокращённое представление для применения стилей к элементам. Оно соответствует приведённому ниже синтаксису:

<!-- Atomic CSS программные сокращения -->.
<!-- syntax:
shortform( property)
property - значение, которое должно быть применено к указанной сокращённой форме
 shortform(property):behavior
behavior может быть hover, active, focus и т.д.
 shortform(property):behavior--screenSize
screenSize: lg - большой, md - средний и sm - маленький
 shortform(property)::pseudo-class
pseudo-classes может быть a - after, b - before, ph - placeholder и т.д.
-->
<!-- Примеры сокращённых форм: D - для display, C - для color и Bg - для background. Их применение показано ниже -->
<div class="D(n)"></div>
<!-- Приведённый выше код устанавливает для display значение none -->
<p class="C(#333)">hello</p>
<!-- Приведённый код устанавливает цвет текста на #333 -->
<div class="Bg(transparent):hover--lg"></div>
<!-- Приведённый код применяет свойство background: transparent; при наведении на div на большом экране -->

SMACSS

(Scalable and Modular Architecture for CSS): SMACSS — это соглашение об именовании CSS, которое обеспечивает простоту сопровождения, поскольку код CSS должен быть разделён на пять основных категорий:

• Base/Базовое: В категории Base указываются стили, применяемые к общим элементам HTML, таким как body, div, p, span и т.д.
• Layout/Макет: Как следует из названия, этот раздел предназначен для организации кода, влияющего на основные макеты страниц веб-приложения. Это могут быть header и footer, навигация, боковые меню и т.д.
• Module/Модули: Категория модули включает в себя многократно используемые компоненты кода или модули, которые могут быть использованы в ходе разработки проекта. Примерами таких стилей могут быть стили кнопок, компоненты карточек и т.д.
• State/Состояние: Категория Состояние содержит поведенческие атрибуты других классов и может быть использована для изменения их внешнего вида на основе заданных критериев. Сюда относятся стили для работы с активными, отключёнными или скрытыми элементами.
• Theme/Тема: Эта последняя категория связана с использованием стилей для применения цветовых тем к проекту. В отличие от других соглашений об именовании, SMACSS в основном применяет логическую организационную структуру стилей CSS, используя пять рассмотренных выше категорий. Пример SMACSS приведён в блоке кода ниже:

/* Base styles */
body {
 font-family: monospace;
}
/* Layout styles */
.header {
 color: #fff;
}
/* Module styles */
.button {
 padding: 10px 20px;
 cursor: pointer;
}
/* State styles */
.form-input:focus {
 background-color: #0056b3;
}
/* Theme styles */
.theme-dark {
 background-color: #333;
}

Благодаря организации стилей CSS в различные категории кодовые базы CSS становятся более структурированными и легко масштабируются, что положительно сказывается на читабельности и возможности повторного использования кода.

Применение соглашений об именовании CSS в существующих проектах

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

Стратегии внедрения соглашений об именовании в текущих проектах

• Обучение и тренинг: Первым шагом к внедрению соглашения об именовании является изучение выбранного соглашения об именовании, его использования и областей применения. Соответствующая документация и учебные материалы могут быть предоставлены команде разработчиков для того, чтобы все её члены были ознакомлены с принципами и правилами соглашения об именовании.
• Постепенное внедрение: В данном случае необходимо постепенно рефакторить существующий код по частям, чтобы принять соглашение об именовании, а не пытаться изменить всю кодовую базу одновременно. Это позволяет избежать перегруженности участников и снизить вероятность возникновения ошибок, обеспечивая плавный переход.
• Совместная работа: В проектах, создаваемых коллективом, разработчики должны работать в группах, чтобы внедрить соглашение об именовании. Такая практика позволяет всем членам команды лучше понять применение соглашения об именовании.
• Автоматизированная линтинг или форматирование CSS: Это предполагает добавление автоматического плагина, который обеспечивает соблюдение правил именования, выдаёт предупреждения при нарушении именования и немедленно предоставляет обратную связь команде разработчиков.
• Регулярный анализ кода: По мере внедрения процесса именования возникает необходимость в периодическом анализе кода, чтобы убедиться в том, что соглашение об именовании применяется лаконично и последовательно.
• Документирование соглашения об именовании: В кодовую базу должно быть добавлено руководство по стилю, определяющее тип соглашения об именовании, правила и примеры его применения. Это необходимо для справочных целей и в качестве руководства при приёме новых участников.
• Стандартизация именования и префиксов: Использование принятого соглашения об именовании (например, имён блоков БЭМ или классов Atomic CSS) должно быть стандартизировано и одинаково в рамках всего проекта для обеспечения согласованности.

Инструменты и методы рефакторинга существующего CSS-кода

Следующие инструменты/техники помогают в процессе рефакторинга существующего кода:

• Использование системы контроля версий, например Git, для отслеживания изменений и облегчения отката в случае аномального поведения или нежелательных изменений в кодовой базе.
• Добавление в кодовую базу плагинов для линтинга и форматирования кода с целью облегчения рефакторинга кода в соответствии с установленными правилами.
• Переименование классов осуществляется постепенно, переходя от родительских элементов к дочерним и родственным. Это позволяет не нарушать работу приложения, а также легко отслеживать и управлять изменениями.
• Регулярное тестирование кода на предмет получения желаемых результатов и отсутствия непредвиденных побочных эффектов для внешнего вида веб-приложения.

Заключение

В сфере frontend разработки важность чистого и эффективного кодирования трудно переоценить. В этой статье мы рассмотрели влияние чистого кода на эффективность разработки и удобство сопровождения, а также преимущества написания эффективного CSS-кода. Одним из основных способов достижения чистоты и эффективности CSS является использование чётко определённых соглашений об именовании. Соглашения об именовании CSS играют ключевую роль в организации и структурировании кодовых баз, что позволяет повысить эффективность совместной работы, читаемость кода и удобство сопровождения. Применяя осмысленные и согласованные имена классов, разработчики могут повысить ясность своего кода и улучшить его многократное использование в различных проектах. Разработчиков следует поощрять к тому, чтобы они с самого начала внедряли соглашения об именовании CSS в свои рабочие процессы. Начиная работу с хорошо организованных и продуманно названных классов, команды разработчиков могут опираться на прочный фундамент, уменьшая количество потенциальных ошибок и конфликтов и способствуя формированию целостного стиля кодирования.