Перевод статьи CSS Code Smells с сайта css-tricks.com для CSS-live.ru, автор — Робин Рендл

Каждую неделю (или вроде того) мы публикуем рассылку, содержащую актуальные ссылки, советы и трюки по веб-дизайну и разработке. В конце мы обычно описываем изученное за неделю. Это необязательно напрямую связано с CSS или фронтенд-разработкой, но там всегда есть чем поделиться. Данный пример — один из таких разделов рассылки, в котором я расскажу о качестве кода, и то, что, на мой взгляд, должно считаться «запашком» CSS-кода.

Многие разработчики жалуются на CSS. Этот каскад! Эти непонятные названия свойств! Вертикальное выравнивание! В языке есть много странных вещей, особенно если вы лучше знакомы с языками программирования вроде JavaScript,  Ruby, и пр.

Однако, реальная проблема CSS состоит, на мой взгляд, в том, что он не сложен, но и не лёгок. Я веду к тому, что изучить его синтаксис можно довольно быстро, но вот научиться писать поистине «хороший» CSS — задача не из лёгких. Возможно, за пару недель вы можете запомнить все свойства и значения, и делать реально красивые дизайны в браузере, и всё, вы уже на «ты». Но это немного не то, что я называю «хорошим» CSS

Чтобы определить что это такое, для начала нужно понять, что такое плохой CSS. В других областях программирования разработчики обычно говорят о «запашках» кода при описании плохого кода: что-то в программе, что подсказывает, мол, «чувак, возможно то, что ты пишешь, не очень хорошая идея». Это может быть что-то простое вроде системы наименования или особенно хрупкого куска кода.

Ниже я привёл свой список «запашков» кода, который, надеюсь, поможет нам определить плохой дизайн и CSS. Заметьте, что все эти пункты основаны на моём личном опыте построения весьма масштабных проектов и сложных приложений, так что, относитесь к ним без фанатизма, пожалуйста.

«Запашок» кода №1: одно то, что вы пишете CSS, уже говорит об этом

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

• Изучите работу текущей системы и её ограничения, и придерживайтесь их.
• Переосмыслите базовую инфаструктуру CSS

Полагаю, этот подход прекрасно описан тут:

О ложной быстроте «исправлений на скорую руку» (автор — Пит Лейси)

«Запашок» кода №2: имена файлов

Скажем, для вашего приложения понадобилась страница поддержки. Первым делом вы, вероятно, создадите CSS-файл «support.scss» и начнёте писать код вроде этого:

.support {
  background-color: #efefef;
  max-width: 600px;
  border: 2px solid #bbb;
}

Итак, проблема тут скорее не в стилях, а в первую очередь в самой идее «страницы поддержки». При написании CSS нужно мыслить гораздо шире: в шаблонах или компонентах, а не в конкретном контенте, который пользователь увидит на странице. Таким образом можно заново переиспользовать что-то вроде «card» на каждой странице, включая и этот экземпляр для страницы поддержки.

.card {
  background-color: #efefef;
  max-width: 600px;
  border: 2px solid #bbb;
}

Уже немного лучше! (Моим следующим вопросом мог быть «Что такое карточка, что может быть внутри неё, когда не стоит использовать карточку, и так далее, и тому подобное») — такие вопросы, вероятно, возникают из-за проблем в дизайне, и помогут вам сосредоточиться на них.

«Запашок» кода №3: стилизация HTML-элементов

По опыту скажу, что, стилизация HTML-элементов (вроде <section> или <p>) — это почти всегда какой-нибудь хак. Есть только один случай, где стилизация HTML-элементов уместна:

section { display: block; }
figure { margin-bottom: 20px; }

И это в так называемом глобальном «сбросе стилей» приложения. Иначе код становится хрупким и сложным в поддержке, поскольку нам абсолютно не ясно, являются ли эти стили хаком для конкретной цели или это стили по умолчанию для этого элемента.

«Запашок» кода №4: вложенность кода

Вложенность кода Sass, в случае, когда дочерние компоненты находятся в родительском элементе — практически всегда код с «запашком» и верный признак того, что этот дизайн требует рефакторинга. Вот пример:

.card {
  display: flex;
  
  .header {
    font-size: 21px;
  }
}

Здесь мы говорим, что класс .header можно использовать только внутри .card? Или это переопределение ещё одного блока CSS в еще каком-то месте нашего кода? Сам факт возникновения такого вопроса указывает на главную проблему здесь: теперь насчёт этого кода есть сомнения. Для понимания работы этого кода приходится знать и другие его части. И если возник вопрос, откуда взялся и как работает этот код, то вероятно он слишком сложный или поддерживать его в будущем станет невозможно.

Это ведёт к пятому пункту кода с «запашком»…

«Запашок» кода №5: переопределение CSS

В идеальном мире мы сначала задаём дефолтные стили для всех элементов в CSS-файле сброса, а затем используем отдельные CSS-файлы для каждой кнопки, поля формы и компонента в нашем приложении. Код не должен переопределяться каскадом более одного раза. Во-первых, так общий код становится более предсказуемым, а во-вторых, это делает код компонента (к примеру, button.scss) крайне читабельным. Теперь, чтобы пофиксить что-либо, нужно открыть единственный файл и все изменения применятся ко всему приложению одним махом. В случае с CSS, предсказуемость — это всё.

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

«Запашок» кода №6: CSS-файлы с 50 и более строками кода

Чем больше вы пишете CSS, тем сложнее и хрупче становится код. Поэтому, как только я вижу около 50 строк CSS, я стараюсь переосмыслить то, что разрабатываю, задав себе пару вопросов. Начало и конец которых: «Это один компонент или его можно разбить на отдельные части, работающие независимо друг от друга?»

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

Заключение

Полагаю, у меня теперь появился ещё один вопрос, но уже для вас: что для вас CSS с «запашком»? Что значит плохой, а что реально хороший CSS? Обязательно поделитесь в комментариях ниже.

P.S. Это тоже может быть интересно:

• Псевдокласс :has() — не только «родительский селектор»
• CSS-выражения от контейнера для дизайнеров
• Тёмная сторона CSS: выходим за рамки и взрываем звезды с border-image и градиентами