Руководство по написанию кода от @mdo
Наверное, все уже слышали про Bootstrap, создателем которого и является Марк Отто (@mdo). В этом замечательном руководстве понятно расписаны все основные положения, которые в любом случае касаются вас и вашего кода. Сам Марк предлагает нам строго соблюдать предложенные в этом руководстве правила или собственные соглашения — и правильно делает, нет ничего лучше самоконтроля. В руководстве присутствуют рекомендации по написанию кода как на HTML, так и на CSS.
Главный слоган, который описывает весь смысл любого руководства по написанию кода:
Каждая строка кода должна казаться написанной только одним человеком, вне зависимости от количества разработчиков.
Пересказывать это руководство я не буду - просто оставлю здесь ссылку на него, тем более есть перевод на наш великий и могучий:
Предупреждение
Со временем начинаешь понимать, что предела совершенству нет и быть не может, поэтому пытаешься каждый раз улучшить что-то в своём коде. Иногда это может доходить до того, что один и тот же проект может начинаться с нуля до десятка раз, пока ищется тот самый стиль и норма. Это нормальная, прекрасная практика, но не забывайте, скоро дедлайн и никого не волнует, что вы искали свой стиль и достигали совершенства - важен результат.
Личный опыт
Структура проекта
Создайте папку, в которой будет находиться ещё одна папка... — Нет, ну правда, создайте уже себе шаблон, которым вы будете пользоваться при каждом старте разработки нового проекта. Это очень удобно и практично, нежели каждый раз создавать всю структуру проекта заново, снова и снова создавая папки и файлы внутри них.
Попробуйте начать с чего-то, похожего на это, конечно, если вы используете какой-нибудь препроцессор:
app/ ├── styles/ │ ├── vendor/ │ │ └── vendor.min.css │ ├── common/ │ │ └── variables.less │ ├── library/ # Какие-либо библиотеки, необходимые при разработке │ │ └── material-colors.less │ ├── mixins/ # Примеси │ │ └── clearfix.less │ ├── modules/ # Модули, такие как база, типографика, списки и т.д. │ │ └── typography.less │ ├── partials/ # Части шаблона: header, footer, main, page-* и т.д. │ │ └── header.less │ └── scaffolding.less # Точка входа ├── scripts/ │ ├── vendor/ │ │ └── bootstrap.min.js │ └── main.js ├── images/ │ ├── touch/ │ │ └── apple-touch-icon-precomposed.png │ └── ... ├── fonts/ │ └── ... └── index.html
Заголовки файлов
Давайте заголовки в начале файлов, так проще ориентироваться, если вы работаете с уже разросшимся веб-приложением, где файлов аршином не измерить, да умом не понять.
К слову, в проекте Raptorius Web Kit я использую такой шаблон заголовков для файлов:
// ---------------------------------------------------------------
// Папка -> Файл
// ---------------------------------------------------------------
Так, для файла header.less заголовок будет таким:
// ---------------------------------------------------------------
// Partials -> Header
// ---------------------------------------------------------------
А в проекте uikit используется довольно обширный заголовок:
// Name: Comment
// Description: Defines styles for comment threads
//
// Component: `uk-comment`
//
// Sub-objects: `uk-comment-header`
// `uk-comment-avatar`
// `uk-comment-title`
// `uk-comment-meta`
// `uk-comment-body`
// `uk-comment-list`
// `uk-comment-primary`
//
// Markup:
//
// <!-- uk-comment -->
// <article class="uk-comment">
// <header class="uk-comment-header">
// <img class="uk-comment-avatar" src="avatar.svg" width="50" height="50" alt="">
// <h4 class="uk-comment-title"></h4>
// <div class="uk-comment-meta"></div>
// </header>
// <div class="uk-comment-body">
// <p></p>
// </div>
// </article>
//
// ========================================================================
Попробуйте придумать свой формат, чтобы в будущем было проще ориентироваться в стилях самому и другим разработчикам.
Комментируйте блоки
Если вы читали руководство по написанию кода от @mdo, то в самом конце вы могли заметить пункт про комментирование блоков кода. Запомните эту рекомендацию она очень важна и понадобится вам в будущем.
Хотелось бы добавить: если используете сокращения в комментариях, то учтите, что в какой-то момент получающаяся аббревиатура может совпасть с написанным кодом.
Посмотрим на классический пример:
// RDE block comment
// ---------------------------------------------------------------
Допустим, что вы ищите через поиск этот блок по запросу rde, но получаете в итоге:
.comment {
border: 1px solid #ccc;
}
Плохо. Приходится искать в поиске дальше.
Отличной идеей будет использовать какой-нибудь префикс в комментарии:
// =RDE block comment
// ---------------------------------------------------------------
Имена классов
Посмотрите на следующий код:
.banner { ... }
.profile { ... }
.box { ... }
.comment { ... }
.list { ... }
Вы можете сказать к чему относятся эти стили? Вы точно уверены, что они не перекрываются дальше или у них нет двойников? — Нет, не спорьте. Просто будьте информативнее, пожалуйста.
Куда лучше, если классы будут иметь имена типа:
.user-profile { ... }
.comment-box { ... }
.article-comment { ... }
.features-list { ... }
Прекрасно! Идём дальше.
Вложенность элементов
Посмотрите на следующий код:
.header .right-area .user-profile .dropdown .dropdown-menu > a { ... }
Узнаёте свой код? - У меня для вас плохие новости. Не нужно так писать - это плохая практика, которой порой начинают грешить все, кто использует CSS-препроцессоры.
Решается этот недуг личным правилом, которое может звучать примерно так: "Хороший код может быть вложенным лишь на 3-4 уровня, если это не так, то нужно попробовать пересмотреть этот блок".
Таким образом, если целью было изменить, допустим, цвет ссылки, то "хороший" код будет таким:
.user-profile .dropdown-menu > a { ... }
Дочерние элементы
Если вы разрабатываете блок, содержащий только определённые элементы, то используйте CSS-селектор, который будет выбирать только непосредственные дочерние элементы.
.dropdown-menu > li > a { ... }
.user-profile > .photo { ... }
.header-logo > a { ... }
Нужно это лишь для того, чтобы повысить производительность. При использовании этого селектора, браузер сопоставляет лишь один элемент с одним селектором. И несложно прикинуть, как картина будет выглядеть при рендеринге, когда будут использоваться сотни элементов и сотни селекторов. А прикинуть очень просто - нужно всего лишь перейти по ссылке и нажать на кнопку запуска теста.
Инструменты
CSS-препроцессоры
Вы до сих пор не используйте препроцессор? — мне вас жаль. Серьёзно.
На дворе уже 2014 год и не использовать препроцессор — преступление. Нужно срочно обдумать на какой препроцессор вы перейдёте в ближайшее время. Вы не можете не использовать его. Это экономит время и расширяет возможности. Причём это совсем несложно. Поверьте. Вас уже ждут на сайтах: Less, Sass, Stylus. Пришло время перемен ваших инструментов.
Автоматическая расстановка браузерных префиксов
Расставляете браузерные префиксы вручную? — Тогда вам нужен замечательный постпроцессор Autoprefixer.
Всё очень просто: вы указываете минимально поддерживаемую версию браузера или необходимые версии выборочно и постпроцессор обработает ваш CSS код, в соответствии с данными сайта Can I Use.
Вместо тысячи слов: перейдите на сайт, на котором присутствует демо и следуйте инструкции ниже.
Вы напишите вот это:
:fullscreen a {
transition: transform 1s;
}
А получите вот такую простыню кода:
:-webkit-full-screen a {
-webkit-transition: -webkit-transform 1s;
transition: transform 1s;
}
:-moz-full-screen a {
transition: transform 1s;
}
:-ms-fullscreen a {
transition: transform 1s;
}
:fullscreen a {
-webkit-transition: -webkit-transform 1s;
transition: transform 1s;
}
Удобно и не нужно запоминать какие свойства надо использовать с префиксом в данный момент.
Регулярная проверка
Все мы люди, и людям свойственно ошибаться, иначе никак. Рано или поздно наступает тот момент, когда уследить за всем кодом самому становится сложно, и тут на помощь приходит CSS LINT. Сервис проверяет синтаксис, а также пытается выявлять признаки неэффективности на основе правил, которые могут быть изменены в соответствии с вашими требованиями к сервису.
Старайтесь регулярно проверять свои файлы стилей, чтобы в один момент вам не пришлось исправлять всё и сразу.
Сортировка свойств
CSSComb — это та самая штука, что поможет вам поддерживать однотипную последовательность CSS-свойств по заданному порядку в любом проекте.
Для ознакомления с полными возможностями инструмента посетите Хабрахабр.
Feedback
На данный момент я использую все эти технологии, но, к сожалению, всего сразу не припомнишь и возможно что-то упущено. Я уверен, что есть сотни других интересных инструментов, которые многие ещё не видели и, возможно, они даже чем-то лучше приведенных в этой статье.
А какие инструменты используете вы?