Написание кода сложно. Есть много вещей, о которых нужно знать, много подводных камней, которых следует избегать, и всегда есть место для улучшений. Использование Sass делает написание CSS немного менее сложным. Если вы не делаете это неправильно, в этом случае это делает CSS еще хуже.
Чтобы избежать этого, я хочу поделиться парой трюков, которые помогут вам лучше написать Sass.
Используйте index() вместо нескольких равных назначений
Я люблю пересматривать код Sass. Я могу часами копаться в коде Sass в репозиториях GitHub. Что-то, что я вижу довольно часто, особенно в средах Sass, — это использование нескольких равных назначений.
Допустим, вы хотите проверить, является ли значение initial , inherit или auto . Обычный способ написать это так:
@if $value == "initial" or $value == "inherit" or $value == "auto" { // Then do something }
Хотя это хорошо работает, не только уродливо, но и довольно долго писать. Что если бы мы просто использовали вместо этого функцию index() ? Эта функция …
Возвращает позицию значения в списке. Если значение не найдено, вместо этого возвращается
null.
Sass ссылка
Давайте обновим наш пример кода с помощью этого блестящего инструмента:
@if index("initial" "inherit" "auto", $value) { // Then do something }
Некоторые утверждают, что index() возвращает число, а не логическое значение, поэтому использовать его не следует. Это действительно вопрос выбора здесь. Я думаю, что это прекрасно, так как мы только хотим убедиться, что он не возвращает ноль (что было бы ложно), но если вы действительно хотите иметь дело с логическим значением, вы все равно можете сделать:
@if not not index("initial" "inherit" "auto", $value) { // Then do something }
Вы, вероятно, знаете, как преобразовать значение в логическое значение в JavaScript: !!value . Это точно то же самое, но с not . Добавление not раньше, чем выражение преобразует его в логическое значение, но обратное значение. При добавлении другого not , он все еще является логическим, но снова изменяет значение, чтобы сохранить первоначальное значение.
В нашем случае вместо числа, если оно является одним из трех значений, или null если это не так, оно является true или false . Опять же, в этом контексте это ничего не добавляет к исходному утверждению.
Если вас беспокоит, что все это снижает смысл исходного выражения, вы можете создать короткую функцию для этого:
@function is($value, $values) { @return not not index($values, $value); }
А потом:
@if is($value, "initial" "inherit" "auto") { // Then do something }
В любом случае, моя точка зрения такова: не используйте несколько одинаковых назначений, когда вместо них можно использовать функцию index() .
Используйте @warn
Если есть функция, которая часто упускается из виду разработчиками Sass, это директива @warn . Это очень плохо, потому что это когда вещи начинают веселиться. @warn дает вам возможность распечатывать сообщения в консоли прямо из Sass:
Директива @warn выводит значение выражения SassScript в стандартный поток вывода ошибок. Это полезно для библиотек, которым необходимо предупреждать пользователей об устаревших или исправляющихся ошибках.
Sass ссылка
Это удивительный инструмент, чтобы предупредить разработчика:
- Потенциальные ошибки
- Устаревшие
- Действия, предпринятые Sass без согласия разработчика
- В чем дело
Первый в этом списке является наиболее полезным, поскольку у Sass еще нет директивы @error . Поэтому, когда вы делаете миксин / функцию, проверяйте заданные аргументы, чтобы убедиться, что они в порядке; если это не так, предупредите разработчика (и верните ложное значение). Например:
@function color($color) { @if not map-has-key($colors, $color) { @warn "No color found for `#{$color}` in `$colors` map."; } @return map-get($colors, $color); }
Примечание. Для получения дополнительной информации об обработке ошибок в Sass я написал подробную статью на эту тему для Tuts +.
Что касается других вариантов использования для @warn , некоторые библиотеки используют его, чтобы осудить некоторые миксины по мере их продвижения вперед; как бурбон .
@mixin inline-block { display: inline-block; @warn "inline-block mixin is deprecated and will be removed in the next major version release"; }
Sass-MQ от Guardian использует его, чтобы предупредить разработчика при попытке преобразовать значение без единиц измерения в em . Умный ход, учитывая это, может быть неоднозначным.
@function mq-px2em($px, $base-font-size: 16px) { @if (unitless($px)) { @warn "Assuming #{$px} to be in pixels, attempting to convert it into pixels for you"; @return mq-px2em($px + 0px); // That may fail. } @else if (unit($px) == em) { @return $px; } @return ($px / $base-font-size) * 1em; }
Я мог бы также вспомнить случай, когда он распечатывает конфигурацию важного миксина, когда создается его экземпляр, своего рода напоминание о том, что приложение загружается, с данным conf.
Используйте argList для неизвестного числа аргументов
Всякий раз, когда вы создаете функцию или миксин, который принимает список значений любой длины, вам, вероятно, следует использовать argList а не простой list . argList — это технический тип данных для того, что мы называем переменными аргументами .
Иногда для миксина или функции имеет смысл принять неизвестное количество аргументов. Например, миксин для создания теней может принимать любое количество теней в качестве аргументов. Для этих ситуаций Sass поддерживает «переменные аргументы», которые являются аргументами в конце объявления mixin или функции, которые принимают все оставшиеся аргументы и упаковывают их в виде списка. Эти аргументы выглядят как обычные аргументы, но сопровождаются
...
Sass ссылка
Почему argList лучше? С технической точки зрения это не так. Неважно, является ли это list или list argList , вы сможете выполнять одни и те же операции над обоими, так зачем беспокоиться об этом?
Короче, потому что это что-то значит. При использовании argList вы явно argList , что в нем может содержаться любое количество значений, ограничений нет, и проверка длины не будет выполняться, пока этот argList живет . Между тем использование обычного list — это просто способ упаковать несколько значений в одну переменную. Возможно, вы захотите, чтобы эти несколько значений были 2. Или 3. Или 4. Любое конкретное число. Как это:
// Function doing something with a key/value pair from a map // --- // @param [list] $pair: key/value pair // --- @function map-key-value-pair($pair) { @if not length($pair) == 2 { @warn "`map-key-value-pair` function is expecting a list of 2 items, #{length($pair)} given."; @return false; } // Then do something }
С другой стороны, здесь есть случай, когда вам нужен argList а не list :
// Returns the highest value // --- // @param [argList] $values: numbers // --- @function max($values...) { $max: nth($values, 1); @for $i from 2 through length($values) { $value: nth($values, $i); @if $value > $max { $max: $value; } } @return $max; }
В этом случае наличие list не имеет особого смысла, но наличие argList придает значение функции, даже из сигнатуры! Так что это в значительной степени семантическая проблема, так как нет почти никакой разницы между двумя типами данных.
Используйте псевдонимы
Это для тех из вас, кто строит фреймворки, сеточные системы, расширения Compass и кто знает, что еще с Sass. Когда вы создаете API, сделайте это как можно более понятным. Неважно, если ваши имена функций / миксинов немного длинные, если они имеют смысл.
Но если вы не хотите вводить одну и ту же длинную функцию снова и снова, создайте псевдонимы. Тогда разработчик должен решить, будут ли они использовать неясные псевдонимы или явные имена.
Например:
@function get-configuration($option) { @return map-get($global-configuration, $option); }
Правда, get-configuration() довольно длинный для ввода. Итак, создайте псевдоним, возвращающий результат get-configuration() :
@function conf($opt) { @return get-configuration($opt); }
Вот и ты. API понятен благодаря оригинальной функции и прост в использовании с псевдонимом. Не пытайтесь использовать код для краткости, оно того не стоит.
Последние мысли
Как видите, именно мелочи превращают средний кусок кода в нечто привлекательное для работы. Всякий раз, когда у вас есть время и забота о проекте, обязательно отшлифуйте его столько, сколько сможете. Приятно осознавать, что вы очистили и оптимизировали свой код как можно лучше!