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

Для этого кодовая база должна быть чистой и единообразной. Чистой, потому что поддержка запутанного кода весьма проблематична, а единообразной потому что это облегчает и ускоряет поддержку кодовой базы. Если код выглядит везде одинаково, то намного проще привыкнуть к способу его написания.

Добиться чистоты и единообразия кода в Sass можно двумя способами. Первый это следование правилам и руководствам по написанию кода, таким как CSS Guidelines или Sass Guidelines. Второй — автоматическая проверка (линтинг) вашего кода.

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

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

Для проверки кода Sass есть один, но очень мощный инструмент: SCSS-lint. Начнем с плохого — SCSS-lint это модуль Ruby и независимо от того, как вы собираетесь его запускать (из командной строки, таск-менеджера или текстового редактора), сначала вам придется его установить. Хорошей новостью будет то, что уже ведется работа над портированием SCSS-lint в виде пакета NPM, так что со временем установка Ruby модуля будет необязательной. Ну, а пока мы начинаем с команды:

$ gem install scss_lint

Примечание: согласно правилам именования модулей Ruby, gem называется scss_lint, в то время как в командной строке используется название scss-lint. А библиотека называется SCSS-lint. Все совсем просто…

Используем scss-lint в командной строке

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

Опция -c или --config используется для указания места нахождения файла с конфигурационными настройками, применяемыми при линтинге кодовой базы. Например:

$ scss-lint . --config .scss-lint.yml

В зависимости от особенностей вашего проекта, вы можете исключить из проверки отдельные файлы или каталоги с помощью опции -e или --exclude . Это могут быть используемые в проекте готовые библиотеки или установленные вами модули node, например:

$ scss-lint . --exclude ./node_modules/**/*

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

Существуют и другие опции, но для начала работы хватит и этих.

Первым аргументом, передаваемым scss-lint, должен быть путь к проверяемому каталогу. Если он не указан, по умолчанию это ., текущий каталог. При желании вы можете задать для линтинга лишь один из каталогов:

scss-lint ./assets/stylesheets

Настройка линтеров

Теперь мы готовы к проверке нашего кода Sass и нам нужно определиться с правилами этой проверки. В SCSS-lint есть набор отдельных линтеров, перечислять их все будет слишком долго, ознакомиться с полным списком можно в документации.

Идея состоит в том, чтобы создать файл YAML с конфигурацией линтеров в корневом каталоге проекта. По умолчанию SCSS-lint ищет файл .scss-lint.yml в текущем каталоге и я рекомендовал бы вам называть файл с настройками именно так. Однако вы можете задать и другое имя, только не забудьте передать его вместе с опцией --config.

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

Линтинг при коммитах

Очень полезным будет линтинг кода при коммите с помощью хука (перехватчика) перед коммитом (pre-commit hook). Подробнее о хуке перед коммитом вы можете узнать из моей предыдущей статьи, в которой я писал о тестировании библиотеки Sass.

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

Обеспечение проверки кода перед отправкой в репозиторий это отличный пример использования перехватчика в Git. В этом разделе мы рассмотрим, как это можно настроить максимально простым способом.

Мы будем делать это с помощью небольшого пакета npm, поддерживающего хуки Git через настройки в файле package.json. Существует много библиотек с таким функционалом, но я лично предпочитаю pre-commit. Вот вся настройка:

{
  "scripts": {
    "lint": "scss-lint ."
  },
  "pre-commit": [
    "lint"
  ]
}

При коммите этот хук запускает скрипт npm lint (fyfkjubxyj pfgecre npm run lint). А lint в свою очередь запускает команду scss-lint. Если SCSS-lint возвращает ошибку коммит отменяется до исправления кода.

Если вы запускаете SCSS-lint через Gulp, Grunt или что-либо еще, вы можете включить эту задачу в линтер npm вместо ручного запуска scss-lint. При этом вы также можете передавать опции --config или --exclude.

Заключение

Можно было бы рассмотреть эту тему подробнее, но я думаю, что это неплохое введение в SCSS-lint, достаточное, чтобы использовать его на существующих и новых проектах.

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