Вы вынуждены придерживаться руководящих принципов компании, установленных в камне в 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 ? Вынуждает ли ваша компания следовать странным методам разработки?