CSS GuideLines, часть 1. Синтаксис и форматирование
CSS не идеален. Поначалу кажется, что он прост в освоении, но работая над реальным проектом вы столкнетесь со многими проблемами. Мы не можем изменить то, как работает CSS, но мы можем изменить тот код, который мы пишем.
- Разработчик должен писать поддерживаемый код;
- Разработчик должен писать прозрачный, читаемый код;
- Разработчик должен писать масштабируемый код.
Важность руководства по оформлению кода
- разрабатывают и поддерживают продукты в течение определенного времени;
- имеют разработчиков с разным уровнем умений и с разными специальностями;
- имеют определенное количество разработчиков, постоянно работающих над чем-либо;
- регулярно нанимают новых разработчиков;
- имеют определенное количество исходников, с которыми постоянно работают разные люди.
- Установление стандарта качества кода для всех исходников;
- Обеспечение согласованности между исходниками;
- Следование стандартам всеми разработчиками;
- Увеличение продуктивности.
Дисклеймер
CSS StyleGuide — это сборник обязательных к применению техник и методологий. Это всего лишь сборник рекомендаций, проверенных на моем личном опыте. Применять их или нет — решать уже вам.
Синтаксис и форматирование
Один из простейших видов руководств по оформлению кода (далее — стайлгайдов, прим. переводчика) — это набор правил касательно синтаксиса и форматирования. Наличие правил по оформлению CSS-стилей означает то, что код всегда будет понятен всем членам вашей команды.
Чистый код дарит ощущение чистоты. С чистым кодом намного приятнее работать, такой код подталкивает других членов команды также соблюдать стандарты написания кода. Грязный код ужасен и отвратителен, с ним никому не захочется работать.
- 4 пробела для отступов. Именно пробелы, а не таб;
- Строки не длиннее 80 символов;
- Мультистрочный CSS;
- Эффективное использование пустого пространства.
Разбиение на несколько файлов
После стремительного роста популярности CSS-препроцессоров многие разработчики стали чаще разбивать свой CSS-код на отдельные файлы. Даже если вы не используете препроцессоры, было бы хорошо поместить самостоятельные части кода в отдельные файлы, а затем соединять их в один файл при сборке проекта (например, с помощью Grunt или Gulp).
Если вы по каким-либо причинам отказываетесь от использования множества файлов, то следующие шаги могут потребовать небольших корректировок.
Таблица содержимого
Добавление оглавления в CSS-файлы это довольно трудозатратно, но эти затраты окупаются с лихвой. Да, от разработчика потребуется прилежность, чтобы вовремя править оглавление и поддерживать в нем актуальную информацию. Но зато вся команда получит единую таблицу с информацией о том, что содержится в CSS-файле, что он делает и в каком порядке в нем располагаются стили.
Например, самый простой вариант оглавления — добавить название раздела и его описание:
/** * CONTENTS * * SETTINGS * Global. Globally-available variables and config. * * TOOLS * Mixins. Useful mixins. * * GENERIC * Normalize.css. A level playing field. * Box-sizing. Better default `box-sizing`. * * BASE * Headings. H1–H6 styles. * * OBJECTS * Wrappers. Wrapping and constraining elements. * * COMPONENTS * Page-head. The main page header. * Page-foot. The main page footer. * Buttons. Button elements. * * TRUMPS * Text. Text helpers. */ Естественно, на многих проектах оглавление может быть значительно больше, но, надеюсь, в этом примере видно, как оглавление в основном CSS-файле проекта может дать разработчику понятие о том, что, где и как используется в проекте.
Ширина строки в 80 символов
- Возможность держать перед собой сразу несколько открытых файлов, размещенных друг возле друга;
- Возможность просматривать CSS на таких сайтах, как Github, или в окне терминала;
- Обеспечение комфортной длины строки для добавления комментариев.
/** * Я — очень длинный комментарий. Я детально описываю CSS-код подо мной. Я * настолько длинный комментарий, что я превышаю лимит в 80 символов, * поэтому я разбит на несколько строк. */ Следует отметить, что есть и исключения для этого правила — например, строки с длинными URL-адресами.
Именование секций кода
Каждый крупная секция CSS-кода должна начинаться так:
Добавление символа «#» в начале названия секции позволит нам выполнять поиск по файлу намного быстрее. Есть вероятность того, что запрос «SECTION TITLE» вернет много результатов, в то время как запрос с решеткой в начале вернет нам только один нужный результат. Также стоит оставлять пустую строку между названием секции и первым селектором.
Если вы работаете над проектом, в котором каждая секция помещена в свой отдельный файл, то название секции должно находиться в самом начале этого файла. Если же в вашем проекте в одном файле есть несколько секций, то разделяйте последний селектор и название новой секции пятью пустыми строками. Это позволяет значительно повысить читаемость кода, особенно при просматривании длинных файлов.
/*------------------------------------*\ #A-SECTION \*------------------------------------*/ .selector <> /*------------------------------------*\ #ANOTHER-SECTION \*------------------------------------*/ /** * Comment */ .another-selector <> Анатомия CSS-правил
Прежде чем поговорить о том, как разработчикам следует писать CSS-правила, давайте уточним используемую терминологию:
- Связанные селекторы на одной строке, несвязанные селекторы на разных строках;
- Пробел перед открывающей скобкой ( <);
- Свойства и их значения на одной строке;
- Пробел после двоеточия, относящегося к свойству;
- Каждое объявление свойства и его значения на новой строке;
- Открывающая скобка находится на той же строке, что и последний селектор;
- Первое объявление свойства находится на новой строке после открывающей скобки;
- Закрывающая скобка находится на отдельной строке:
- Каждое объявление имеет отступ в 4 пробела;
- Точка с запятой находится сразу после значения свойства, без пробела.
Таким образом, пример ниже будет являться неправильным:
- Табы вместо пробелов;
- Несвязанные селекторы на одной строке;
- Открывающая скобка на отдельной строке;
- Закрывающая скобка на той же строке, что и последнее объявление;
- Точка с запятой (кстати говоря, необязательная именно в последнем объявлении) в конце последнего объявления не стоит;
- Нет пробелов после двоеточий.
Мультистрочный CSS
- Снижение риска появления конфликтов при слиянии объявлений за счет того, что каждое объявление находится на отдельной строке;
- Более надежные и читаемые diff’ы, потому что одна строка несет только одно изменение.
.icon < display: inline-block; width: 16px; height: 16px; background-image: url(/img/sprite.svg); >.icon--home < background-position: 0 0 ; >.icon--person < background-position: -16px 0 ; >.icon--files < background-position: 0 -16px; >.icon--settings
- Они по-прежнему соответствуют правилу об одном изменении на одной строке;
- Они достаточно похожи друг на друга, чтобы объединить их в один блок кода; их не надо читать с той же тщательностью, что другие самостоятельные правила.
Отступы
Так же, как вы делаете отступы для объявлений, делайте и отступы у связанных наборов правил:
Благодаря этому разработчик сразу увидит, что .foo__baz располагается внутри .foo__bar, который, в свою очередь, находится внутри .foo. Такой способ имитации DOM многое рассказывает разработчикам о том, где класс располагается, благодаря чему не приходится каждый раз открывать разметку и искать нужный кусок кода.
Отступы в Sass
Sass предоставляет возможность вкладывать правила друг в друга. Это означает, что написав такой scss-код:
… мы получим следующий скомпилированный CSS:
Работая с Sass, следует использовать те же 4 пробела для отступов, а также оставлять пустую строку перед и после вложенных правил. К слову, вложенности в Sass следует избегать. Об этом еще будет сказано в следующих частях.
Выравнивание
По возможности, выравнивайте схожие строки со свойствами:
Это в разы упрощает жизнь разработчикам, чьи текстовые редакторы поддерживают редактирование нескольких строк одновременно.
Разумное использование пустого пространства
- Одну пустую строку между связанными наборами правил;
- Две пустые строки между несвязанными наборами правил;
- Пять пустых строк между секциями.
/*------------------------------------*\ #FOO \*------------------------------------*/ .foo <> .foo__bar <> .foo--baz <> /*------------------------------------*\ #BAR \*------------------------------------*/ .bar <> .bar__baz <> .bar__foo <> Никогда не должно получаться так, что пустой строки между правилами нет. Пример ниже неправильный, так делать не стоит:
HTML
Учитывая тесную связь между HTML и CSS, с моей стороны было бы неправильно не оговорить некоторые моменты относительно разметки.
Всегда обрамляйте атрибуты кавычками, даже несмотря на то, что код будет работать и без кавычек. Просто формат с кавычками наиболее привычен для большинства разработчиков, и такой формат позволяет избежать множества ошибок.
Но предпочтительно использовать такой код:
При записи нескольких значений в атрибут, разделяйте эти значения двумя пробелами:
Когда несколько классов связаны друг с другом, рассмотрите способ их обрамления в скобки:
Это не строгая рекомендация, и я все еще тестирую это в своих проектах, но такой способ влечет за собой ряд преимуществ. Подробнее об этом читайте в статье «Группирование связанных классов в разметке».
Как и в случае с нашими табилцами стилей, в разметке тоже можно использовать пустое пространство. Например, почему бы не разделять важные секции контента пятью пустыми строками:
Разделяйте независимые, но близко связанные части разметки одной пустой строкой:
Такой способ улучшает читаемость кода, а также позволяет некоторым текстовым редакторам (Vim, например) легко манипулировать такими частями разметки.