Проверка нашего кода профессионалом — отличный способ улучшить качество кода, но что произойдет, если у вас нет доступа к программисту Rockstar? Вы делаете следующую лучшую вещь и захватываете «пух» для этого языка.
Сегодня я хотел бы немного поговорить о CSSLint , недавно выпущенном инструменте анализа кода для, как вы уже догадались, CSS. Присоединяйся ко мне после прыжка!
Что такое линт?
Давайте поразим Википедию для определения:
Lint — это инструмент, который отмечает подозрительное использование программного обеспечения, написанного на любом компьютерном языке.
По сути, Линт смотрит на наш код и проверяет плохие методы программирования. Неопределенные переменные, неэффективные конструкции и тому подобное.
Вы, наверное, удивляетесь, зачем вам такой инструмент. Посмотрим правде в глаза: не все из нас обладают высочайшим знанием того, с чем мы работаем, и не могут позволить себе роскошь пересмотреть наш код. В этих случаях следующий код лучше всего вставить в код. И в отличие от инструментов очистки, lint выкладывает лакомые кусочки о вашем коде и о том, как его улучшить.
Представляем CSSLint
CSSLint, созданный Николасом Закасом и Николь Салливан , представляет собой инструмент с открытым исходным кодом, который проверяет ваш синтаксис на соответствие заранее заданным правилам, чтобы устранить возможные недостатки и убедиться, что ваша презентация работает, как ожидается, с небольшими сюрпризами.
Перейдя на сайт CSSLint, вы можете просто вставить свой исходный CSS и выбрать, какие правила вы хотите применить. Нажмите кнопку Lint, и CSSLint начнет разрушать вашу самодовольство.
Если вы любитель Node, как я, то есть версия для этого. Просто введите sudo npm install -g csslint и все sudo npm install -g csslint !
Правила CSS Lint
Давайте кратко рассмотрим правила, применяемые CSSLint.
- Ошибки разбора должны быть исправлены
- Не используйте смежные классы
- Удалить пустые правила
- Используйте правильные свойства для отображения
- Не используйте слишком много поплавков
- Не используйте слишком много веб-шрифтов
- Не используйте слишком большие шрифты
- Не используйте идентификаторы в селекторах
- Не указывайте заголовки
- Стили заголовков должны быть определены только один раз
- Нулевым значениям не нужны единицы
- Свойства с префиксом поставщика также должны иметь стандарт
- CSS-градиенты требуют всех префиксов браузера
- Избегайте селекторов, которые выглядят как регулярные выражения
- Остерегайтесь сломанных коробочных моделей
- Не используйте @import
- Не используйте! Важно
- Включить все совместимые префиксы поставщиков
- Избегайте дублирования свойств
Если вы чем-то похожи на меня, то некоторые правила, должно быть, приводили вас в замешательство.
Имеют ли правила смысл?
Откровенно говоря, да, нет, и все между ними.
Побывав на нескольких дискуссионных форумах и в комнатах IRC, я обнаружил, что многие разработчики, кажется, в шоке от правил и, возможно, именно так. Позвольте мне попытаться объяснить, почему большинство правил имеют смысл, а другие нет.
Спорные правила
Не используйте идентификаторы в селекторах
Идентификаторы не должны использоваться в селекторах, потому что эти правила слишком тесно связаны с HTML и не имеют возможности повторного использования. Гораздо предпочтительнее использовать классы в селекторах, а затем применять класс к элементу на странице.
Это поразило многих разработчиков, поскольку мы привыкли назначать идентификаторы для основных структурных компонентов макета, таких как верхний и нижний колонтитулы.
CSSLint утверждает, что стилизация для таких элементов по определению не может быть напрямую использована повторно. Если вам нужны двойные боковые панели на странице, класс позволяет вам повторно использовать стили, а идентификатор — нет.
Имейте в виду, что только то, что класс можно использовать повторно, не означает, что так должно быть. Уникальные классы являются вполне приемлемыми и отличным способом повторного использования стиля, если возникнет такая необходимость.
Не указывайте заголовки
Элементы заголовка (h1-h6) должны быть определены как стили верхнего уровня, а не ограничены определенными областями страницы.
Большинство разработчиков, включая меня, привыкли к написанию контекстно-зависимых заголовков. Например, мы определяем отдельные стили для заголовков в зависимости, скажем, на какой странице они отображаются. Аргумент в пользу этого подхода состоит в том, что он перемещает все разметки от разметки к таблице стилей. Вы можете просто определить тег и разрешить CSS-каскад соответственно.
CSSLint утверждает, что такой подход ставит под угрозу предсказуемость вашего дизайна. Если кто-то другой выберет ваш дизайн и попытается вставить заголовок где-нибудь, ему / ей необходимо знать контекст и расположение элемента. С заголовками, определенными безусловно, он или она может использовать заголовок в любом месте, уверенном в его представлении, независимо от его родителей.
Стили заголовков должны быть определены только один раз
Заголовочные элементы (h1-h6) должны иметь ровно одно правило на сайте.
Расширение вышеприведенного правила для улучшения предсказуемости представления. Правильно или неправильно, имейте в виду, что это в основном исключает включение некоторого кода сброса в вашу таблицу стилей. Каждый лист сброса также работает с вашими заголовками, поэтому CSSLint пометит его как ошибку.
Сомнительные правила
Не используйте смежные классы
Смежные классы выглядят как .foo.bar. Хотя это технически разрешено в CSS, они не обрабатываются должным образом в Internet Explorer 6 и более ранних версиях.
Если это правило включено, CSSLint помечает правила, как .nav.red , по официальной причине, что Internet Explorer 6 и ниже не очень хорошо работает с селектором. Я уважаю разработчиков, но я должен не согласиться здесь. Только потому, что он не работает с Интернетом, «Dev-buster» Explorer 6 не является хорошей причиной, чтобы перестать работать с полезной функцией.
Остерегайтесь сломанных коробочных моделей
Границы и отступы добавляют пространство вне содержимого элемента. Установка ширины или высоты вместе с границами и отступами обычно является ошибкой, потому что вы не получите желаемого визуального результата. CSS Lint предупреждает, когда правило использует ширину или высоту в дополнение к отступам и / или рамке.
Боксовая модель может быть сломана, но почти каждый знакомый разработчик хорошо знает недостатки и способы преодоления различий в реализации. Действительно ли мы готовы отказаться от контроля, потому что некоторые старые браузеры имеют другую реализацию?
Не используйте слишком много веб-шрифтов
Использование веб-шрифтов влияет на производительность, поскольку файлы шрифтов могут быть довольно большими, и некоторые браузеры блокируют рендеринг при их загрузке. По этой причине CSS Lint предупредит вас, когда в таблице стилей будет более пяти веб-шрифтов.
Я не предвижу ситуацию, когда я буду использовать более пяти шрифтов на странице, но я чувствую, что погружение в эту территорию немного сомнительно. Во всяком случае, это недостаток дизайна, чем недостаток развития. Если разработчик ссылается на пять отдельных шрифтов в своей таблице стилей, скорее всего, это не случайно.
Не используйте слишком много поплавков, то есть абстрагируйте функциональность
CSS Lint просто проверяет, использовали ли вы float более 10 раз, и если да, отображает предупреждение. Использование этого числа с плавающей точкой обычно означает, что вам нужна какая-то абстракция для создания макета.
Хотя я согласен с аргументом создателей о том, что наличие более десяти экземпляров с плавающей точкой является плохой идеей, я также чувствую, что это повлияет на разметку после превышения заданного размера.
Например, в ситуации, когда вы хотите использовать два элемента, традиционно вы используете:
|
1
2
|
<div class=»container-1″></div>
<div class=»container-2″></div>
|
… и стиль, традиционными методами.
|
1
2
|
.container-1 { width: 70%;
.container-2 { width: 30%;
|
Метод CSSLint будет абстрагировать float следующим образом:
|
1
2
|
<div class=»container-1 float»></div>
<div class=»container-2 float»></div>
|
… и стиль так:
|
1
2
3
|
.container-1 { width: 70%;
.container-2 { width: 30%;
.float { float: left;}
|
Хотя я согласен с тем, что это жизнеспособный подход, я чувствую, что разметка будет значительно переполнена, как только вы попытаетесь абстрагироваться больше. Я бы предпочел увидеть класс, содержащий большую часть его стиля в одном месте, чем загромождать разметку более чем 10 классами. Опять же, я чувствую, что это субъективная тема.
Очевидные правила
- Удалить пустые правила
- Избегайте дублирования свойств
- Нулевым значениям не нужны единицы
- Свойства с префиксом поставщика также должны иметь стандарт
- Ошибки разбора должны быть исправлены
- Включить все совместимые префиксы поставщиков
- … остальные правила
Все вышеперечисленные правила соответствуют действующим стандартным практикам. Несомненно, некоторые из правил имеют небольшое значение в реальном мире, например, нулевые значения не нуждаются в единицах измерения, или будут обнаружены приличной IDE, например, при синтаксическом анализе ошибок, но, тем не менее, это хорошие правила для набора тестов CSS.
Несколько проблем
CSSLint поможет многим разработчикам в будущем, но …
CSSLint, без сомнения, написан разработчиками с большими полномочиями и определенно поможет многим разработчикам и дизайнерам в будущем.
Что я нахожу немного утомительным, так это то, что многие противоречивые правила исходят от объектно-ориентированного CSS, фреймворка CSS, предназначенного для того, чтобы позволить разработчикам писать поддерживаемый CSS. Хотя я ничего не имею против фреймворка и его парадигмы, вы должны согласиться, что это способ делать вещи, а не способ делать вещи.
В отличие от JSLint, где я чувствую, что все правила имеют смысл, с CSSLint мне кажется, что мне говорят, что один стиль написания CSS правильный, а другие неправильные. Это было бы как кто-то, кто просил меня отказаться от Битлз, потому что Rolling Stones — их любимая группа.
Это всего лишь инструмент
Инструменты — это всего лишь инструменты.
Конечно, мы, как группа, склонны довольно цепляться за код. Нам не нравится слышать, что наш код может * задыхаться * потенциальные проблемы или быть написан совершенно по-другому.
Здесь следует отметить, что CSSLint, в конечном счете, является инструментом. Это просто позволяет вам знать, что в некоторых областях могут быть ошибки.
CSSLint не должен быть железным кулаком, на котором вы основываете все свое эго. Нет причин наклоняться назад, чтобы избежать предупреждения, если вы точно знаете, что делаете.
Итак, вы должны начать использовать CSSLint?
Да.
В CSS, как и в интегральном исчислении, есть много решений данной проблемы. Не обязательно существует «лучший» способ сделать что-то — вы можете предпочесть удобочитаемость, а я — эффективность. Важно то, что вы понимаете, что у каждого из нас есть свой уникальный способ ведения дел.
Если у вас нет одинаковых взглядов на решение проблемы, вы можете не согласиться с другим подходом и даже посчитать его сомнительным.
Сказав это, никогда не будет веской причины не учиться чему-то новому. Взгляд на проблемы с точки зрения другого разработчика — отличный способ узнать, сможете ли вы узнать что-то новое.
Завершение
Что вы думаете о CSSLint? Считаете это полезным? Смешение? Помогло ли это с вашими проблемами в реальном мире? Дайте нам знать об этом в комментариях.
Будьте превосходны друг другу и большое спасибо за чтение!