CSS GuideLines, часть 1.Синтаксис и форматирование

Введение

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

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

• Разработчик должен писать поддерживаемый код;
• Разработчик должен писать прозрачный, читаемый код;
• Разработчик должен писать масштабируемый код.

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

Важность руководства по оформлению кода

Руководство по оформлению кода — это ценный инструмент для команд, которые:

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

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

Хорошее руководство по оформлению кода позволит добиться следующего:

• Установление стандарта качества кода для всех исходников;
• Обеспечение согласованности между исходниками;
• Следование стандартам всеми разработчиками;
• Увеличение продуктивности.

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

Дисклеймер

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-файлах 80 символами. Причины делать так:

• Возможность держать перед собой сразу несколько открытых файлов, размещенных друг возле друга;
• Возможность просматривать CSS на таких сайтах, как Github, или в окне терминала;
• Обеспечение комфортной длины строки для добавления комментариев.

/**
 * Я — очень длинный комментарий. Я детально описываю CSS-код подо мной. Я
 * настолько длинный комментарий, что я превышаю лимит в 80 символов, 
 * поэтому я разбит на несколько строк.
 */

Следует отметить, что есть и исключения для этого правила — например, строки с длинными URL-адресами.

Именование секций кода

Каждый крупная секция CSS-кода должна начинаться так:

/*------------------------------------*
    #SECTION-TITLE
*------------------------------------*/

.selector {}

Добавление символа "#" в начале названия секции позволит нам выполнять поиск по файлу намного быстрее. Есть вероятность того, что запрос «SECTION TITLE» вернет много результатов, в то время как запрос с решеткой в начале вернет нам только один нужный результат. Также стоит оставлять пустую строку между названием секции и первым селектором.

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

/*------------------------------------*
    #A-SECTION
*------------------------------------*/

.selector {}





/*------------------------------------*
    #ANOTHER-SECTION
*------------------------------------*/

/**
 * Comment
 */

.another-selector {}

Анатомия CSS-правил

Прежде чем поговорить о том, как разработчикам следует писать CSS-правила, давайте уточним используемую терминологию:

[селектор] {
    [свойство]: [значение];
    [<--объявление--->]
}

Например:

.foo, .foo--bar,
.baz {
    display: block;
    background-color: green;
    color: red;
}

В этом куске кода вы можете видеть:

• Связанные селекторы на одной строке, несвязанные селекторы на разных строках;
• Пробел перед открывающей скобкой ({);
• Свойства и их значения на одной строке;
• Пробел после двоеточия, относящегося к свойству;
• Каждое объявление свойства и его значения на новой строке;
• Открывающая скобка находится на той же строке, что и последний селектор;
• Первое объявление свойства находится на новой строке после открывающей скобки;
• Закрывающая скобка находится на отдельной строке:
• Каждое объявление имеет отступ в 4 пробела;
• Точка с запятой находится сразу после значения свойства, без пробела.

Такой способ оформления по большому счету является общепринятым и универсальным способом (исключая количество пробелов для отступа; многие разработчики предпочитают использовать два пробела вместо четырёх).

Таким образом, пример ниже будет являться неправильным:

.foo, .foo--bar, .baz
{
	display:block;
	background-color:green;
	color:red }

Проблемы из этого примера:

• Табы вместо пробелов;
• Несвязанные селекторы на одной строке;
• Открывающая скобка на отдельной строке;
• Закрывающая скобка на той же строке, что и последнее объявление;
• Точка с запятой (кстати говоря, необязательная именно в последнем объявлении) в конце последнего объявления не стоит;
• Нет пробелов после двоеточий.

Мультистрочный CSS

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 { background-position: -16px -16px; }

Эти типы правил можно записывать на одной строке, потому что:

• Они по-прежнему соответствуют правилу об одном изменении на одной строке;
• Они достаточно похожи друг на друга, чтобы объединить их в один блок кода; их не надо читать с той же тщательностью, что другие самостоятельные правила.

Отступы

Так же, как вы делаете отступы для объявлений, делайте и отступы у связанных наборов правил:

.foo {}

    .foo__bar {}

        .foo__baz {}

Благодаря этому разработчик сразу увидит, что .foo__baz располагается внутри .foo__bar, который, в свою очередь, находится внутри .foo. Такой способ имитации DOM многое рассказывает разработчикам о том, где класс располагается, благодаря чему не приходится каждый раз открывать разметку и искать нужный кусок кода.

Отступы в Sass

Sass предоставляет возможность вкладывать правила друг в друга. Это означает, что написав такой scss-код:

.foo {
    color: red;

    .bar {
        color: blue;
    }

}

… мы получим следующий скомпилированный CSS:

.foo { color: red; }
.foo .bar { color: blue; }

Работая с Sass, следует использовать те же 4 пробела для отступов, а также оставлять пустую строку перед и после вложенных правил. К слову, вложенности в Sass следует избегать. Об этом еще будет сказано в следующих частях.

Выравнивание

По возможности, выравнивайте схожие строки со свойствами:

.foo {
    -webkit-border-radius: 3px;
       -moz-border-radius: 3px;
            border-radius: 3px;
}

.bar {
    position: absolute;
    top:    0;
    right:  0;
    bottom: 0;
    left:   0;
    margin-right: -10px;
    margin-left:  -10px;
    padding-right: 10px;
    padding-left:  10px;
}

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

Разумное использование пустого пространства

Так же, как и при использовании отступов, мы можем дать разработчику много информации, правильно используя пустое пространство между правилами.
Используйте:

• Одну пустую строку между связанными наборами правил;
• Две пустые строки между несвязанными наборами правил;
• Пять пустых строк между секциями.

Пример:

/*------------------------------------*
    #FOO
*------------------------------------*/

.foo {}

    .foo__bar {}


.foo--baz {}





/*------------------------------------*
    #BAR
*------------------------------------*/

.bar {}

    .bar__baz {}

    .bar__foo {}

Никогда не должно получаться так, что пустой строки между правилами нет. Пример ниже неправильный, так делать не стоит:

.foo {}
    .foo__bar {}
.foo--baz {}

HTML

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

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

Этот код будет работать:

<div class=box>

Но предпочтительно использовать такой код:

<div class="box">

При записи нескольких значений в атрибут, разделяйте эти значения двумя пробелами:

<div class="foo  bar">

Когда несколько классов связаны друг с другом, рассмотрите способ их обрамления в скобки:

<div class="[ box  box--highlight ]  [ bio  bio--long ]">

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

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

<header class="page-head">
    ...
</header>





<main class="page-content">
    ...
</main>





<footer class="page-foot">
    ...
</footer>

Разделяйте независимые, но близко связанные части разметки одной пустой строкой:

<ul class="primary-nav">

    <li class="primary-nav__item">
        <a href="/" class="primary-nav__link">Home</a>
    </li>

    <li class="primary-nav__item  primary-nav__trigger">
        <a href="/about" class="primary-nav__link">About</a>

        <ul class="primary-nav__sub-nav">
            <li><a href="/about/products">Products</a></li>
            <li><a href="/about/company">Company</a></li>
        </ul>

    </li>

    <li class="primary-nav__item">
        <a href="/contact" class="primary-nav__link">Contact</a>
    </li>

</ul>

Такой способ улучшает читаемость кода, а также позволяет некоторым текстовым редакторам (Vim, например) легко манипулировать такими частями разметки.

Материалы для дополнительного изучения

• «Группирование связанных классов в разметке»

Автор: Scorpion97

Источник