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

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

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

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

В этом посте мы рассмотрим, как мы можем разумно оптимизировать наш CSS с помощью руководств по стилю кода CSS..

Руководства по стилю кода и библиотеки шаблонов

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

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

Как руководства по стилю кода, так и библиотеки шаблонов включают стратегию стиля, но разного рода. Библиотеки шаблонов, такие как Bootstrap, Zurb Foundation, Global Experience Language BBC или библиотека шаблонов 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 color: #bad; 

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

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

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

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

С помощью только имена семантических селекторов Также важно, если мы хотим иметь значимый код. Например, вместо .красная кнопка (который не показывает, что делает кнопка), лучше использовать .Оповещение кнопки имя (которое говорит, что он делает), так как таким образом мы даем возможность разработчикам (и нашим будущим я) понять, что делает эта кнопка.

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

Правила форматирования

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

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

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

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

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

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

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

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

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

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

.class // хорошее поле: 0; // плохое поле: 0px; // неверное поле: 0em; // неверное поле: 0rem; 

Комментирование

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

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