Как оптимизировать CSS с помощью руководств по стилю кода

Примечание редактора: эта статья является частью нашей серии «Оптимизация кода», в которой мы рассмотрим, как оптимизировать кодирование для повышения эффективности в стремлении стать лучшими программистами.

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

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

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

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

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

И руководства по стилю кода, и библиотеки шаблонов включают в себя стратегию стиля, но разного рода. Библиотеки шаблонов, такие как начальная загрузка, Zurb Foundation, BBC Global Experience Language, или Библиотека шаблонов MailChimpпредоставьте нам пользовательский интерфейс с готовыми CSS-классами, типографикой, цветовой схемой, иногда сеткой и другими шаблонами дизайна.
Руководства по стилю кода CSS, такие как Evernote-х или ThinkUp-х (или упомянутые во введении) содержат правила о том, как писать CSS, включая такие вещи, как соглашения об именах, структура файлов, порядок свойств, форматирование кода и другие.
Обратите внимание, что руководство по стилю жизни, такие как KSS, Styledown, или Pattern Labгенерировать библиотеки шаблонов и не Руководства по стилю кодирования. Хотя библиотеки шаблонов также очень полезны и улучшают процесс веб-разработки, они не позволяют нам оптимизировать сам код.
Создайте свое руководство по стилю кода CSS
Конечная цель руководства по стилю кода CSS состоит в том, чтобы гарантировать, что мы можем работать с согласованной, легко отлаживаемой базой кода, написанной разработчиками, которые следуют одинаковым правилам стилизации кода. Создание руководства по стилю кода CSS может занять немного времени, но оно того стоит, так как мы должны сделать это только один раз. Тогда мы можем использовать одно и то же руководство по стилю для разных проектов.

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

Например, AirBnB показывает хорошие и плохие примеры разработчикам в следуя легко усваиваемому пути:
Файловая структура

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

Некоторые руководства по стилю, такие как ThinkUp-хтакже предупреждает нас о том, что нельзя использовать встроенные или встроенные стили, если это неизбежно; это также полезное правило, которое стоит применять.

гнездование

Вложение – отличная функция в CSS, но иногда она может выйти из-под контроля. Никто не чувствует себя особенно счастливым, особенно в середине разочаровывающего процесса отладки, натыкаясь на очень длинные селекторы, подобные этому:

.class_1 .class_2 # id_1 # id_2 li a span {
цвет: # плохой;
}
Поэтому всегда полезно установить разумный предел вложенности, например, GitHub выбрал три уровня в его руководство по стилю, Ограничивая вложение, мы также можем заставить себя писать более структурированный код.

Правила именования

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

Четырьмя общими стилями, используемыми в именовании селекторов, являются .lowercase, .under_scores, .dash-es и .lowerCamelCase. Можно выбрать любой из них, но мы должны следовать той же логике во всем проекте.

Использование только семантических имен селекторов также важно, если мы хотим иметь осмысленный код. Например, вместо .red-button (которая не показывает, что делает кнопка) лучше использовать имя .alert-button (которая говорит, что она делает), так как таким образом мы включаем разработчиков (и наши будущие “я”). ) чтобы понять, что делает эта кнопка.

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

Форматирование кода включает такие вещи, как использование пробелов, табуляции, отступов, пробелов, разрывов строк и т. Д. В действительности форматирование не является универсально хорошим или плохим методом, единственное практическое правило – выбирать согласованные правила, которые приводят к читаемому коду, и следовать им до конца.

Dropbox например, требует от разработчиков ставить пробелы после двоеточия в объявлениях свойств, в то время как Evernote использует два пробела для отступа. Мы можем установить столько правил форматирования, сколько нам удобно, но не более, чем это возможно понять.

Порядок декларирования

Упорядоченные вещи всегда легче увидеть, а упорядочение объявлений CSS (свойств с их значениями) в соответствии с правилом, которое имеет смысл, приводит к лучшей организации кода.

Взгляните, например, на WordPress правила заказа недвижимости, он определяет следующую простую, но логичную основу для упорядочения, в которой свойства группируются по их значению:

1. дисплей
2. позиционирование
3. Модель коробки
4. Цвета и типография
5. Другой

Единицы и ценности

Решение о том, как мы хотим использовать единицы измерения и значения, важно не только для достижения единообразного внешнего вида кода, но и если мы этого не сделаем, у нас может получиться что-то странное

Представьте себе сайт, который поочередно использует измерения длины px, em и rem. Он не будет выглядеть плохо только в редакторе кода, но, скорее всего, некоторые элементы будут на удивление маленькими или большими на этом сайте.

Нам также необходимо принять решение о значениях цвета (шестнадцатеричное, rgb или hsl) и о том, хотим ли мы использовать сокращенные свойства и в соответствии с какими правилами. Существует инструкция, которая включена в каждое руководство по стилю кода CSS, в которое я натолкнулся, то есть не указывайте единицы измерения для значений 0 (на самом деле, просто не указывайте).
.учебный класс {
// хорошо
поле: 0;

// плохой
поле: 0px;

// плохой
поле: 0em;

// плохой
поле: 0rem;
}
Комментирование

Комментирование кода необходимо на всех языках, но в CSS это не только облегчает отладку и создание документации, но также делит правила CSS на логические группы. Мы можем использовать либо / * … * /, либо стиль обозначения // … для комментариев в CSS, важно соблюдать согласованность с комментариями на протяжении всего нашего проекта.

Идиоматический CSS например, устанавливает значимую систему комментирования, которая даже использует некоторые основные ASCII искусствои приводит к красиво организованному коду: