Статьи

Google раскрывает свои руководства по стилю HTML, CSS и JavaScript

Вы вынуждены придерживаться руководящих принципов компании, установленных в камне в 1969 году? Или ваши коллеги-разработчики могут выразить свою художественную сторону встроенным ASCII-искусством?

Мне нравится просматривать руководящие принципы стиля. Обычно существуют очевидные правила, которые кажутся странными, и несколько скрытых драгоценных камней, которые вы раньше не открывали. К сожалению, немногие компании достаточно смелы, чтобы опубликовать внутренние рекомендации. Би-би-си представила свои документы в 2010 году, но Google наконец-то выпустил руководства по стилю, которые компания использует для внутренних проектов.

Правила предоставляются для C ++, Objective C, Python, XML и R — но нас больше всего интересуют HTML, CSS и JavaScript. Документы очень короткие. Я видел слишком много, где разработчики должны изучить 1001 тайные и субъективные правила, которые демонстрируют знания автора, а не дают полезные советы.

Давайте внимательнее посмотрим …

HTML

В руководстве по стилю HTML есть несколько сюрпризов:

  • служить семантическим HTML5 как text / html
  • отдельная разметка, стилизация и скриптинг
  • проверьте вашу разметку, когда это возможно
  • использовать запасные варианты, когда такие технологии, как canvas

Google рекомендует брить каждый байт: файлы должны быть в кодировке UTF-8, завершающий пробел должен быть обрезан, и вы должны избегать ссылок на объекты, таких как & mdash; и & rdquo ;. Они даже рекомендуют опустить дополнительные структуры и закрывающие теги, например

 
<!DOCTYPE html>
<title>Saving money, saving bytes</title>
<p>Qed.

Uggh. Я все за сохранение нескольких байтов, но все же предпочитаю более строгий XHTML-подобный синтаксис.

Странно, но Google рекомендует делать отступ с двумя пробелами, а не с табуляцией. Разве это не вдвое больше необходимого количества пробельных символов ?!

CSS

В руководящих принципах таблицы стилей преобладают дальнейшие передовые практики и методы сохранения байтов:

  • используйте правильный CSS, если не имеете дело с ошибками или проприетарными синтаксисами (префиксы вендоров)
  • используйте короткие идентификаторы и имена классов, но убедитесь, что они не являются загадочными или презентационными (например, # синяя кнопка)
  • рассмотреть префиксные имена для больших проектов, например # xyz-help, .xyz-column
  • когда это возможно, упростите селекторы, например #example, а не ul # example
  • использовать сокращенные синтаксические обозначения
  • не используйте кавычки в url()
  • используйте короткие #abc шестнадцатеричные обозначения цвета вместо #aabbcc
  • заканчивайте каждое объявление точкой с запятой (даже последней)
  • избегать взломов браузера

Google предлагает исключить ведущие нули из измерений, таких как .5em. Это сохраняет символ, но я предпочитаю код, который легче сканировать.

Руководство рекомендует использовать новую строку для каждого разделителя, разделенного запятыми, который применяется к блоку. Я склонен согласиться, хотя я виноват в использовании длинных списков селекторных строк.

Наконец, в нем говорится, что объявления свойств должны быть в алфавитном порядке, например

 
#example
{
	border: 1px solid #000;
	border-radius: 6px;
	display: block;
	font-family: sans-serif;
	margin: 1em;
	outline: 0;
	padding: 10px;
	text-align: center;
}

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

JavaScript

Понятно, что руководство по стилю JavaScript длиннее, но облегчает вам основы:

  • всегда используйте var
  • всегда заканчивать строки точкой с запятой
  • используйте стандартные, а не нестандартные функции
  • используйте константы camelCaseNames и UPPERCASE, но избегайте использования ключевого слова const
  • использовать методы пространства имен
  • избегайте eval()
  • избегать with()for-in
  • использовать массивы и литералы объектов, а не более подробные объявления
  • знать правду и ложные правила
  • не используйте условные комментарии IE в вашем источнике JavaScript
  • не изменяйте прототипы встроенных объектов — это позор, поскольку это одна из более мощных функций JavaScripts, но вы знаете, что это приведет к проблемам
  • используйте замыкания осторожно и не вводите циклические ссылки
  • аналогично, будьте осторожны, используя «это»

Была одна необычная рекомендация: не используйте функции внутри блоков, т.е. напишите:

 
if (x) {
  var foo = function() {}
}

скорее, чем:

 
if (x) {
  function foo() {}
}

Вы увидите второй синтаксис, используемый везде. Это работает без проблем, но это не действительный ECMAScript.

В документе также упоминается, что объекты-обертки никогда не должны использоваться для примитивов, если вы не типизируете. Это может привести к неожиданным результатам, таким как:

 
var x = new Boolean(false);
if (x) {
	// this code evaluates
}

Тупой JavaScript.

Наконец, в руководстве говорится, что вы должны использовать одинарные кавычки (‘) вместо двойных кавычек (“) при разделении строк, которые могут содержать атрибуты HTML. Я использую двойные кавычки везде, и я не уверен, что смогу легко изменить привычку. Тем не менее, я использую одинарные кавычки для статических строк PHP, так что, возможно, я привередлива!

Лучший совет сохраняется на конец документов: будьте последовательны. Разработчики редко соглашаются с любым руководством по программированию, но вы должны следовать своим собственным правилам. Это облегчит жизнь другим, пытающимся понять ваш код и когда вы вернетесь к нему через шесть месяцев.

Согласны ли вы с руководствами по стилю Google ? Вынуждает ли ваша компания следовать странным методам разработки?