Руководство по стилю Sass: Учебное пособие по Sass о том, как писать лучший код CSS

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

Что такое Sass и почему вы должны его использовать?

Для тех из вас, кто не знает, что такое Sass, лучше всего начать с посещения официальной веб-страницы Sass. Sass — это аббревиатура от Syntactically Awesome StyleSheets и расширение CSS, добавляющее мощи и элегантности базовому языку.

Sass — это препроцессор CSS с множеством мощных функций. Наиболее заметными функциями являются переменные, расширения и примеси.

Переменные хранят информацию, которую можно повторно использовать позже, например цвета или другие часто используемые значения. Расширения помогают создавать «классы», допускающие наследование правил. Миксины, вы можете думать о них как о «функциях». Sass также имеет некоторые другие удивительные возможности по сравнению с другими препроцессорами, такие как использование логических операторов (условных выражений и циклов), пользовательских функций, интеграции с другими библиотеками, такими как Compas, и многим другим. Одни только эти функции могут помочь вам и вашей команде работать более продуктивно и, в конце концов, лучше писать CSS.

Зачем вам нужно руководство по стилю CSS

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

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

Гид по стилю

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

Общие правила CSS

Всегда следует соблюдать общие правила. Они в основном сосредоточены на том, как следует форматировать код Sass, чтобы обеспечить согласованность и удобочитаемость кода:

• Для отступа используйте пробелы вместо табуляции. Лучше всего использовать 2 пробела. Вы можете вести свою собственную священную войну с этой опцией, и вы можете определить свое собственное правило и использовать либо вкладки, либо пробелы, либо что вам больше подходит. Важно только определить правило и следовать ему, оставаясь последовательным.
• Включите пустую строку между каждым оператором. Это делает код более понятным для человека, а код пишется людьми, верно?
• Используйте один селектор на строку, например:

 selector1, selector2 { }

• Не включайте пробел между круглыми скобками.

 selector { @include mixin1($size: 4, $color: red); }

• Используйте одинарные кавычки для заключения строк и URL-адресов:

 selector { font-family: 'Roboto', serif; }

• Заканчивайте все правила точкой с запятой без пробелов перед:

 selector { margin: 10px; }

Правила для селекторов

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

• Избегайте использования селекторов ID. Идентификаторы слишком специфичны и используются в основном для действий JavaScript.
• Избегайте !important . Если вам нужно использовать это правило, это означает, что что-то не так с вашими правилами CSS в целом, и ваш CSS плохо структурирован. CSS с множеством !important правил может быть легко использован неправильно, и в результате код CSS будет запутанным и трудным для сопровождения.
• Не используйте дочерний селектор. Это правило основано на тех же рассуждениях, что и правило ID. Дочерние селекторы слишком специфичны и тесно связаны со структурой вашего HTML.

Держите свои правила Sass в порядке

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

1. Сначала используйте @extend . Это позволит вам сначала узнать, что этот класс наследует правила откуда-то еще.
2. Используйте @include далее. Удобно, когда ваши примеси и функции включены вверху, а также позволяет вам знать, что вы будете перезаписывать (при необходимости).
3. Теперь вы можете написать свой обычный класс CSS или правила элемента.
4. Поместите вложенные псевдоклассы и псевдоэлементы перед любым другим элементом.
5. Наконец, напишите другие вложенные селекторы, как в следующем примере:

 .homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ''; } a { } ul { } }

Некоторые соглашения об именах

Часть соглашений об именах в книге стилей основана на двух существующих соглашениях об именах BEM и SMACSS, которые стали популярными среди разработчиков. БЭМ означает блок, элемент, модификатор. Он был разработан командой ЯНДЕКС, и идея БЭМ заключалась в том, чтобы помочь разработчикам понять взаимосвязь между HTML и CSS в проекте. SMACSS, с другой стороны, означает масштабируемую и модульную архитектуру для CSS. Это руководство по структурированию CSS для удобства сопровождения.

Вдохновленные ими, наши правила именования таковы:

• Используйте префикс для каждого типа элемента. Добавляйте к своим блокам префиксы, например: макеты ( l- ), модули ( m- ) и состояния ( is- ).
• Используйте два символа подчеркивания для дочерних элементов для каждого блока:

 .m-tab__icon {}

• Используйте два тире для модификаторов для каждого блока:

 .m-tab--borderless {}

Переменные

Используйте переменные. Начните с более общих и глобальных переменных, таких как цвета, и создайте для них отдельный файл _colors.scss . Если вы заметили, что какое-то значение повторяется в таблице стилей несколько раз, перейдите и создайте новую переменную для этого значения. Пожалуйста, СУШИТЕ. Вы будете благодарны, когда захотите изменить это значение и когда вам нужно будет изменить его только в одном месте.

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

 $red : #f44336; $secondary-red :#ebccd1;

Медиа-запросы

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

 // ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }

Это генерирует такой CSS:

 // Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }

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

Чтобы создать именованные медиа-запросы, создайте свой миксин следующим образом:

 @mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } }

Подробнее об именовании медиа-запросов можно прочитать в следующих статьях: Именование медиа-запросов и Написание лучших медиа-запросов с помощью Sass.

Другие соображения

В заключение, вот некоторые другие соображения, которые вы также должны иметь в виду и которым следует следовать:

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

 .class1 { .class2 { li { //last rules } } }

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

Заключение

Идея этого руководства по стилю состоит в том, чтобы дать вам несколько советов о том, как улучшить способ написания кода Sass. Имейте в виду, что даже если вы не используете Sass, приведенные в этом руководстве советы и правила также применимы, и им рекомендуется следовать, если вы используете Vanilla CSS или другой препроцессор. Опять же, если вы не согласны с каким-либо правилом, измените правило, чтобы оно соответствовало вашему образу мыслей. В конце концов, вы и ваша команда должны либо адаптировать это руководство по стилю, либо использовать другое руководство по стилю, либо создать совершенно новое. Просто определите руководство и начните писать отличный код.