Руководство по написанию кода от @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 { ... }

Прекрасно! Идём дальше.

Вложенность элементов

Вложенность элементов в CSS

Посмотрите на следующий код:

.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-препроцессоры

CSS-препроцессоры

Вы до сих пор не используйте препроцессор? — мне вас жаль. Серьёзно.

На дворе уже 2014 год и не использовать препроцессор — преступление. Нужно срочно обдумать на какой препроцессор вы перейдёте в ближайшее время. Вы не можете не использовать его. Это экономит время и расширяет возможности. Причём это совсем несложно. Поверьте. Вас уже ждут на сайтах: Less, Sass, Stylus. Пришло время перемен ваших инструментов.

Автоматическая расстановка браузерных префиксов

Autoprefixer

Расставляете браузерные префиксы вручную? — Тогда вам нужен замечательный постпроцессор 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

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

Старайтесь регулярно проверять свои файлы стилей, чтобы в один момент вам не пришлось исправлять всё и сразу.

Сортировка свойств

CSSComb

CSSComb — это та самая штука, что поможет вам поддерживать однотипную последовательность CSS-свойств по заданному порядку в любом проекте.

Для ознакомления с полными возможностями инструмента посетите Хабрахабр.

Feedback

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

А какие инструменты используете вы?