x
 
Юрий Мазурский
3 сентября 2020
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Как и любой дру­гой код, ХТМЛ и ЦСС нужно фор­ма­ти­ро­вать. Отфор­ма­ти­ро­ван­ный код проще читать и понимать.

Есть много под­хо­дов к фор­ма­ти­ро­ва­нию кода, но де‑факто есть неглас­ный усто­яв­шийся стан­дарт, кото­рого с незна­чи­тель­ными вари­а­ци­ями при­дер­жи­ва­ется боль­шин­ство про­фес­си­о­наль­ных раз­ра­бот­чи­ков. В Гугле фор­ма­ли­зо­вали этот про­дукт кол­лек­тив­ного разума и пре­вра­тили в стан­дарт оформ­ле­ния кода для исполь­зо­ва­ния в про­ек­тах ком­па­нии. Он опи­сан в стай­л­гай­дах Гугля — их можно исполь­зо­вать как шпар­галку. Мы рас­смот­рим глав­ные принципы.

Делать отступы двумя пробелами и не использовать табы

<ul>
  <li>Да
  <li>Нет
</ul>
.example {
  color: blue;
}

Не использовать прописные буквы в именах элементов, атрибутах и стилях

Плохо
<A HREF="/">Глав­ная</A>
Хорошо
<img src="logo.png" alt="Мяу">
img {
  BORDER: 1px solid #56AAF1;
}
img {
  border: 1px solid #56aaf1;
}

Использовать кодировку UTF‑8

Чтобы задать коди­ровку стра­ницы, нужно доба­вить дирек­тиву в блок head:

<meta charset="utf-8">

Максимально разделять представление, структуру и поведение (скрипты)

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

Плохо
<head>
  <title>При­месь как дуа­лизм</title>
  <link rel="stylesheet" href="reset.css" media="screen">
  <link rel="stylesheet" href="styles.css" media="screen">
  <link rel="stylesheet" href="print.css" media="print">
</head>
<body>
  <h1 style="font-size: 1em;">При­месь как дуа­лизм</h1>
  <p>При пере­ходе к сле­ду­ю­щему уровню орга­ни­за­ции поч­вен­ного покрова резо­на­тор выво­дит <u>транс­цен­ден­таль­ный нон­ак­корд</u>. Але­а­то­рика решает тра­ги­че­ский бабу­визм.<br><center>Адап­та­ция каче­ственно испус­кает керн.</center></p>
</body>
Хорошо
<head>
  <title>Мело­ди­че­ский ташет гла­зами совре­мен­ни­ков</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <h1>Мело­ди­че­ский ташет гла­зами совре­мен­ни­ков</h1>
  <p>Гер­ме­нев­тика регрес­сийно пред­став­ляет собой хам­ба­кер. Все­лен­ная доста­точно огромна, чтобы мишень веро­ятна. Арпе­джио погло­щает дан­ный струк­ту­ра­лизм. Экси­тон при­ни­мает во вни­ма­ние Тукан. Бес­спорно, сверх­про­вод­ник сжи­мает онто­ло­ги­че­ский атом, что дает воз­мож­ность исполь­зо­ва­ния дан­ной мето­дики как уни­вер­саль­ной.</p>
  <p>Наряду с этим коле­ба­ние слу­чайно.</p>
</body>

Использовать обычные символы вместо символьных кодов

Все необ­хо­ди­мые сим­волы уже есть в коди­ровке UTF‑8, нет смысла заме­нять их кодами. Исклю­че­нием могут быть неко­то­рые сим­волы, кото­рые необ­хо­димо экранировать.

Плохо
<p>The currency symbol for the Euro is &ldquo;&eur;&rdquo;.</p>
Хорошо
<p>The currency symbol for the Euro is “€”.</p>

Переносить каждый блочный элемент, пункт списка или элемент таблицы на новую строку и выделять дочерние элементы отступами

<footer>
  <p>Читайте про­дол­же­ние ста­тьи <a href="/next">в нашем све­жем выпуске</a></p>
</footer>
<p>Купить:</p>
<ul>
  <li>Молоко</li>
  <li>Яйца</li>
  <li>Бананы</li>
</ul>
<table>
  <thead>
    <tr>
      <th>Цена</th>
      <th>Коли­че­ство</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1000 ₽</td>
      <td>4</td>
    </tr>
  </tbody>
</table>

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

Плохо
<a class='login'>Войти</a>
Хорошо
<a class="login">Войти</a>

Использовать короткие формы записи правил, где это возможно

Плохо
font-family: Helvetica;
font-style: normal;
font-weight: 500;
font-size: 18px;
line-height: 22px;
border-top-style: none;
margin-top: 0;
margin-bottom: 30px;
margin-left: 20px;
margin-right: 20px;
Хорошо
padding: 0 20px 30px;
border-top: 0;
font: 500 18px/22px Helvetica, sans-serif;

Не писать единицы измерения у нулевых значений

Плохо
border-width: 0px;
margin: 0px 20px;
Хорошо
border-width: 0;
margin: 0 20px;

Избегать названий тегов в селекторах

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

Плохо
ul#example {}
div.error {}
Хорошо
 #example {}
.error {}

Отделять значения свойств пробелом и ставить точку с запятой в конце каждого правила

Плохо
.test {
  display:block;
  height:100px
}
Хорошо
.test {
  display: block;
  height: 100px;
}

Отделять селектор от блока описания правила пробелом

Левую скобку нужно остав­лять на одной строке с селектором:

Плохо
#video{
  margin-top: 1em;
}
#video
{
  margin-top: 1em;
}
Хорошо
#video {
  margin-top: 1em;
}

Переносить каждый селектор и каждое свойство на новую строку

Плохо
a:focus, a:active {
  position: relative; top: 1px;
}
Хорошо
h1,
h2,
h3 {
  font-weight: normal;
  line-height: 1.2;
}

Использовать одинарные кавычки в ЦСС

Плохо
header {
  background: url("bg.png") no-repeat center;
  font-family: "open sans", arial, sans-serif;
}
Хорошо
header {
  background: url('bg.png') no-repeat center;
  font-family: 'open sans', arial, sans-serif;
}

Если при­дер­жи­ваться хотя бы неко­то­рых из пере­чис­лен­ных пра­вил оформ­ле­ния, код ста­нет гораздо проще для восприятия.

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Поделиться
Отправить

Комментарии

Николай Вернер
3 сентября 2020

Дополнительно к описанным, выработал своё правило для ЦСС: всегда группирую свойства по смыслу.

Сперва пишу дисплей и флексы, если есть. Потом последовательно описываю поля-рамки-отступы. За ними — позиционирование. После — параметры текста. За ним — фон и эффекты. И после — прочие свойства, которые встречаются далеко не у каждого элемента. Выглядеть это может так:
css .content-frame { display: block; padding: 0 12px; border: 1px solid #333; margin: 16px 0 32px; position: relative; left: -4px; font: 300 18px/24px Helvetica, sans-serif; color: #333; background: #eee; box-shadow: 0 2px 2px rgba(0,0,0,0.12); }
Мне такой подход постоянно экономит миллисекунды при сканировании кода: всегда знаю, в какой части перечня свойств что искать.

Дима Шишикин
3 сентября 2020

Настроенный линтер помогает быстро привыкнуть к этим правилам.

Максим Семенов
3 сентября 2020

Преттиер (https://prettier.io) помогает автоматически форматировать файлы, согласно заданным правилам. Его можно использовать как плагин для среды разработки. Или использовать вместе с гит-хуками и форматировать файлы при каждом коммите.

Константин Мозговой
3 сентября 2020

Юра, почему лучше делать отступы двумя пробелами? Табами ведь быстрее и удобнее.

Максим Карпов
3 сентября 2020

В чём преимущество отступов в два пробела перед четырьмя? И в чём преимущество отказа от табов? На мой взгляд, отступа в два пробела маловато, код начинает сливаться. С четырьмя же структура читается легче.

Тарас Гордиенко
3 сентября 2020

Записывать дробные значения с нулём.
Плохо:
opacity: .5;
Хорошо:
opacity: 0.5;

Глеб Кемарский
3 сентября 2020

Тарас, Гугл рекомендует обходиться без нуля: https://google.github.io/styleguide/htmlcssguide.html#Leading_0s


Omit leading “0”s in values.
Do not put 0s in front of values or lengths between -1 and 1.
font-size: .8em;

Юрий Мазурский
3 сентября 2020

Два или четыре пробела – дело вкуса. Стоит отметить, что правила принятые в команде приоритетнее любых других правил оформления. Поддерживать одинаковый стиль оформления кода важнее, чем насаждать «правильные» отступы или кавычки. На мой вкус, два пробела лучше, потому что код не уезжает так сильно вправо.

Насчёт табов и пробелов – опасно:
https://www.youtube.com/watch?v=tSIfHvgVeQg

Пробелы понятнее сами по себе. Ширина всегда одинаковая, а табы в разных редакторах могут скакать. Если вы редактируете код в браузере, таб тоже так себе идея.

Глеб Кемарский
3 сентября 2020

Николай, для сравнения — Вордпресс предлагает группировать ЦСС-свойства так:
- Display
- Positioning
- Box model
- Colors and Typography
- Other

Но оговаривается, что главное — порядок вместо хаоса. Можно начинать со свойств, которые кажутся более важными, или просто упорядочивать их по алфавиту.
https://make.wordpress.org/core/handbook/best-practices/coding-standards/css/#property-ordering


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Как бороться с багами? Часть десятая: не утонуть в багах и глюках Как организовать процесс сдачи задачи и код-ревью в рамках спринта? Что нужно, чтобы сайт на Айфоне выглядел также как на Андроиде, а не в два раза меньше? 1 Стоит ли менять работу, если уже порядком поднадоело, но есть новые проекты и в целом хоть какой-то прогресс ощутим?




Недавно всплыло

7 2 Как правильно защитить свою позицию перед заказчиком, который боится «потерять» клиентов 5 Что лучше использовать: спинер или прогрессбар? 5