Форматирование CSS: beautifier для читаемости

Введение

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

Зачем форматировать CSS

Минифицированный код нужен в production — он быстрее грузится. Но в исходниках такой код невозможно поддерживать. Форматирование решает несколько задач:

Читаемость. Отступы и переносы помогают глазу скользить по структуре.
Поддерживаемость. В хорошо отформатированном коде проще найти нужное правило, изменить свойство, добавить новое.
Code review. При проверке pull request отступы и единый стиль экономят время ревьюера.
Onboarding. Новому разработчику легче войти в проект с единым стилем.
Меньше багов. Непарные скобки и пропущенные точки с запятой чаще встречаются в неформатированном коде.

Подробнее про обратный процесс — минификацию — читайте в статье проминификацию CSS.

Базовые правила форматирования

Большинство команд сходятся на следующих правилах. Они не единственно верные, но проверены временем.

Отступы

Используйте 2 пробела на уровень. 4 пробела тоже допустимы, но в CSS уровни вложенности редко глубокие, и 2 пробела визуально компактнее. Табы против пробелов — вечный спор, в современных проектах чаще выбирают пробелы ради предсказуемости в разных редакторах.

/* 2 пробела на уровень */
.button {
  background: #4facfe;
  color: #ffffff;
}

.button .icon {
  width: 16px;
  height: 16px;
}

Один селектор — одна строка

Группы селекторов с общими свойствами записывают каждый с новой строки. Это упрощает чтение и добавление новых селекторов:

/* Плохо */
h1, h2, h3, h4, h5, h6 { margin: 0; }

/* Хорошо */
h1,
h2,
h3,
h4,
h5,
h6 {
  margin: 0;
}

Каждое свойство с новой строки

Запись в одну строку допустима только для очень коротких правил (1–2 свойств). В остальных случаях — каждое свойство на отдельной строке:

/* Допустимо — короткое правило */
.hidden { display: none; }

/* Нормально — обычное правило */
.card {
  background: #ffffff;
  border: 1px solid #e5e7eb;
  border-radius: 8px;
  padding: 24px;
}

Пробел перед фигурной скобкой

Между селектором и открывающей скобкой ставят один пробел. Между двоеточием после свойства и значением — один пробел. После двоеточия в псевдоэлементах (::before) пробела нет.

.card::before {
  content: "";
  display: block;
}

Точка с запятой после последнего свойства

Всегда ставьте точку с запятой, даже после последнего свойства в блоке. Это спасает от багов при добавлении новых строк и упрощает диффы в Git:

/* Плохо — нет точки с запятой */
.card {
  background: #fff;
  padding: 24px   /* легко пропустить при добавлении свойства */
}

/* Хорошо */
.card {
  background: #fff;
  padding: 24px;
}

Порядок свойств

Сортировка свойств внутри правила — отдельная тема. Есть несколько подходов:

Без сортировки. Свойства в порядке добавления. Простой, но неоптимальный вариант.
По типам. Сначала позиционирование, затем блочная модель, потом типографика, фон, эффекты. Самый распространённый подход.
Алфавитная. По алфавиту. Легко автоматизировать, но менее удобна для чтения.
Внешние перед внутренними. Свойства, влияющие на взаимодействие с другими элементами (margin, position), перед свойствами, влияющими на сам элемент (color, background).

/* Подход «по типам» */
.card {
  /* Позиционирование */
  position: relative;
  z-index: 1;

  /* Блочная модель */
  display: flex;
  margin: 16px;
  padding: 24px;
  width: 320px;

  /* Типографика */
  font-family: inherit;
  font-size: 14px;
  line-height: 1.5;
  color: #111827;

  /* Фон и границы */
  background: #ffffff;
  border: 1px solid #e5e7eb;
  border-radius: 8px;

  /* Эффекты */
  box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
  transition: box-shadow 0.2s ease;
}

Инструменты для форматирования

Инструмент	Тип	Особенности
Prettier	Форматер	Де-факто стандарт, минимум настроек
Stylelint	Линтер	Правила качества, можно форматировать
csscomb	Конфигуратор	Сортировка свойств по пресетам
VS Code встроенный	Форматер	«Format Document» через Shift+Alt+F
Online-бьютифайеры	Веб-инструмент	Разовое форматирование без установки

Для разовой задачи удобен нашCSS-форматирование (beautifier) — вставляете код, получаете отформатированный результат, ничего не устанавливается и код не покидает браузер.

Prettier: стандарт индустрии

Prettier — самый популярный форматер в JavaScript-мире. Он поддерживает CSS, SCSS, Less, а также JS, TS, HTML, JSON, Markdown. Идеология Prettier — минимум настроек: команда проекта считает, что споров о стиле быть не должно, есть один правильный вариант.

// .prettierrc
{
  "tabWidth": 2,
  "semi": true,
  "singleQuote": true,
  "printWidth": 80
}

Prettier запускается из CLI или как плагин редактора. При сохранении файла код автоматически форматируется — это снижает когнитивную нагрузку: разработчик не думает о пробелах и скобках.

# Запуск на всех CSS-файлах
npx prettier --write "**/*.css"

# Проверка без изменений (для CI)
npx prettier --check "**/*.css"

Stylelint: линтер для качества кода

Prettier форматирует синтаксис, но не проверяет семантику. Stylelint — линтер, который находит проблемы: дубликаты свойств, неизвестные значения, переопределения, нарушения порядка свойств. Он работает в паре с Prettier: Prettier отвечает за стиль, Stylelint — за качество.

// .stylelintrc
{
  "extends": ["stylelint-config-standard", "stylelint-config-recess-order"],
  "rules": {
    "no-duplicate-selectors": true,
    "no-descending-specificity": null,
    "color-hex-length": "short",
    "declaration-block-no-redundant-longhand-properties": true
  }
}

stylelint-config-recess-order — популярный пресет сортировки свойств по типам. stylelint-config-standard — базовый набор правил от команды Stylelint.

Автоматизация в редакторе

VS Code

Установите расширения Prettier и Stylelint, затем включите форматирование при сохранении:

// .vscode/settings.json
{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[css]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "stylelint.validate": ["css", "scss"]
}

WebStorm / IntelliJ

Встроенный форматер работает из коробки черезCtrl+Alt+L. Для интеграции Prettier подключите расширение «Prettier» и настройте запуск при сохранении.

Автоматизация в CI/CD

Чтобы стиль не зависел от разработчика, форматирование проверяется в CI. Если кто-то запушил неформатированный код — сборка падает. Популярный инструмент — lint-staged в связке сhusky: форматирует только изменённые файлы перед коммитом.

// package.json
{
  "lint-staged": {
    "*.css": ["prettier --write", "stylelint --fix", "git add"]
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
}

Проблемы, которые решает бьютифайер

Несогласованные отступы

В одном файле встречаются табы и пробелы, разное количество отступов. Бьютифайер приводит всё к единому стилю.

Длинные строки

Бесконечная строка с десятком свойств нечитаема. Prettier переносит свойства, оставляя строку в пределах printWidth.

Непарные скобки и пропущенные точки с запятой

Бьютифайер добавляет недостающие точки с запятой и подсвечивает проблемы со скобками.

Несогласованный регистр

#FFFFFF и #ffffff — одно и то же, но несогласованный регистр мешает поиску. Prettier и Stylelint приводят к единому виду.

Когда форматирование вредит

У автоматического форматирования есть минусы:

Большие диффы. Если в старом проекте никогда не было единообразия, первое форматирование затронет каждую строку. Git history станет трудно читать. Решение: форматировать отдельным коммитом.
Потеря ручной группировки. Иногда разработчик намеренно группирует свойства по смыслу. Prettier это игнорирует — для сортировки используйте Stylelint.
Конфликты с CSS-хаками. Старые хаки для IE могут сломаться при форматировании. В современных проектах это не актуально.

Форматирование и производительность

Само по себе форматирование не влияет на скорость рендеринга в браузере — для production используется минифицированная версия. Но есть нюанс: форматированный код весит больше, и если его отдавать «как есть», страница грузится дольше. Поэтому правило простое: исходники — форматированные, продакшен — минифицированный. Подробнее — в статье про минификацию CSS.

Чек-лист хорошего CSS

Единый отступ — 2 пробела.
Каждый селектор в группе на новой строке.
Каждое свойство на своей строке.
Пробел перед { и после :.
Точка с запятой после каждого свойства, включая последнее.
Свойства отсортированы по типам или другому соглашению.
Пустая строка между логическими блоками.
Комментарии у сложных мест и секций.
Нет дублирующихся свойств и селекторов.
Prettier и Stylelint настроены и запускаются при сохранении.

Заключение

Форматирование CSS — это не косметика, а часть инженерной культуры. Чистый код ускоряет разработку, снижает количество багов и облегчает онбординг новых членов команды. Настройте Prettier и Stylelint в проекте, включите форматирование при сохранении, добавьте проверку в CI — и забудьте о спорах «табы или пробелы». Для разовой форматировки больших кусков кода используйте нашCSS-beautifier. А перед публикацией не забудьте минифицировать CSS — об этом читайте в статье про минификацию.