Для тех, кто ещё не в курсе, Google выпускает руководство, которое излагает лучшие (по мнению Google) стилистические практики для написания чистого и понятного кода на JavaScript.
Это не жёсткие правила по написанию валидного JavaScript, а только рекомендации, как придерживаться последовательного и привлекательного стиля, во всех ваших исходных файлах. Это особенно актуально для JavaScript, который благодаря своей гибкости прощает ошибки и допускает широкий выбор стилистических вариантов.
У Google и Airbnb есть два самых популярных руководства по стилю. Если вы много пишите на JS, то я определённо рекомендую Вам ознакомиться с обоими.
Следующие 13 рекомендаций, я считаю самыми интересными и актуальными в руководстве от Google.
Они касаются всего, начиная с горячо обсуждаемых вопросов (табуляция или пробел, и как следует использовать точку с запятой), до некоторых невнятных спецификаций, которые меня удивили. Всё это, безусловно, повлияет в будущем на то, как я пишу JS.
Для каждого правила я дам краткое описание спецификации, а затем соответствующую цитату из руководства по стилю, в котором подробно описывается правило. Там, где это применимо, я также приведу пример стиля на практике и сопоставлю его с кодом, который не соответствует правилу.
Используйте пробелы вместо табуляции
Помимо символа конца строки, символ горизонтального пробела ASCII (0x20), единственный разделитель, который следует использовать в любом месте исходного файла. Это означает, что символы табуляции не используются для отступов.
В руководстве также указывается, что для отступа следует использовать два пробела (а не четыре).
// bad
function foo() {
∙∙∙∙let name;
}
// bad
function bar() {
∙let name;
}
// good
function baz() {
∙∙let name;
}
Точка с запятой — ОБЯЗАТЕЛЬНА
Каждая инструкция должна заканчиваться точкой с запятой. Использование автоматической вставки точки с запятой запрещено.
Я не понимаю, почему кто-то может быть против этого утверждения. Регулярное использование точки с запятой, становится предметом дебатов, как и «табуляция против пробелов». Google твёрдо выступает в защиту точки с запятой.
// bad
let luke = {}
let leia = {}
[luke, leia].forEach(jedi => jedi.father = 'vader')
// good
let luke = {};
let leia = {};
[luke, leia].forEach((jedi) => {
jedi.father = 'vader';
});
Не используйте модули ES6 (пока)
Пока не используйте модули ES6 (т.е. ключевые слова экспорта и импорта), так как их семантика ещё не завершена. Обратите внимание, что эта политика будет пересмотрена, как только семантика будет полностью стандартизирована.
// Don't do this kind of thing yet: //------ lib.js ------ export function square(x) { return x * x } export function diag(x, y) { return sqrt(square(x) + square(y)); } //------ main.js ------ import { square, diag } from 'lib';
Горизонтальное выравнивание не рекомендуется (но и не запрещается)
Такая практика допустима, но, в целом, не рекомендуется «стилем» Google. Не следует продолжать горизонтальное выравнивание даже в местах, где оно уже применялось.
Горизонтальное выравнивание — это практика добавления дополнительных пробелов в коде, чтобы определённые значения, отображались непосредственно под другими значениями в предыдущих строках.
// bad
{
tiny: 42,
longer: 435,
};
// good
{
tiny: 42,
longer: 435,
};
Не используйте var
Объявляйте все переменные с помощью const или let. Используйте const по умолчанию, если переменная не требует переназначения. Ключевое слово var не должно использоваться.
На StackOverflow и в других местах, я все ещё замечаю, что люди используют var в своём коде. Не могу сказать, предают ли они этому особое значение или это просто старая привычка.
// bad var example = 42; // good let example = 42;
Отдавайте предпочтение стрелочным функциям
Стрелочные функции делают синтаксис лаконичным и устраняют некоторые трудности с ним. Отдавайте предпочтение стрелочным функциям, вместо ключевого слова function, особенно для вложенных функций.
Честно говоря, я думал, что стрелочные функции хороши только тем, что они более краткие и приятны глазу. Оказывается, они также служат очень важной цели.
// bad
[1, 2, 3].map(function (x) {
const y = x + 1;
return x * y;
});
// good
[1, 2, 3].map((x) => {
const y = x + 1;
return x * y;
});
Используйте шаблонные строки вместо конкатенации.
Используйте шаблонные строки (разделённые символом `) вместо конкатенации комплексных строк, особенно если используется несколько строковых литералов. Шаблонные строки могут занимать несколько строк.
// bad
function sayHi(name) {
return 'How are you, ' + name + '?';
}
// bad
function sayHi(name) {
return ['How are you, ', name, '?'].join();
}
// bad
function sayHi(name) {
return `How are you, ${ name }?`;
}
// good
function sayHi(name) {
return `How are you, ${name}?`;
}
Не используйте line continuations для длинных строк
Не прерывайте строку внутри строкового литерала обратной косой чертой, в обычных или шаблонных строковых литералах. Несмотря на то, что ES5 допускает это, могут появится неприятные ошибки, если после косой черты окажется пробел. Это будет незаметно при чтении.
Интересно, что Google и Airbnb, не сходятся во мнении об этом правиле (вот спецификация Airbnb).
Google рекомендует объединять более длинные строки (как показано ниже), а руководство по стилю Airbnb, рекомендует ничего с ними не делать и позволить длинным строкам продолжаться столько, сколько им нужно.
// bad (sorry, this doesn't show up well on mobile)
const longString = 'This is a very long string that \
far exceeds the 80 column limit. It unfortunately \
contains long stretches of spaces due to how the \
continued lines are indented.';
// good
const longString = 'This is a very long string that ' +
'far exceeds the 80 column limit. It does not contain ' +
'long stretches of spaces since the concatenated ' +
'strings are cleaner.';
“for… of” — предпочтительная конструкция для циклов for
С ES6, в языке, теперь есть три различных типа цикла for. Использовать можно любой, но предпочтение следует отдавать конструкции
for—of,когда это возможно.
По-моему, это странно, но я включил это в свою статью, потому что довольно интересно, что Google объявляет предпочтительный тип цикла for.
У меня всегда было впечатление, что for... in циклы лучше подходят для объектов, а for... of для массивов. «Правильный инструмент для правильной работы».
Хотя спецификация Google не противоречит этой идее, все же интересно знать, что у них есть предпочтение этому циклу, в частности.
Не используйте eval()
Не используйте eval или функцию (…string) конструктор (кроме загрузчиков кода). Эти функции потенциально опасны и просто не работают в средах CSP.
На страничке MDN для eval() даже есть пометка — “Don’t use eval!”
// badlet obj = { a: 20, b: 30 }; let propName = getPropName(); // returns "a" or "b" eval( 'var result = obj.' + propName );// goodlet obj = { a: 20, b: 30 }; let propName = getPropName(); // returns "a" or "b" let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a
Имена констант должны быть ЗАГЛАВНЫМИ_БУКВАМИ и через нижнее подчёркивание
Для неизменных величин — НЕИЗМЕННО_ПРАВИЛО: всё заглавными, а слова через подчёркивание.
Если вы абсолютно уверены, что переменная не должна изменяться, вы можете указать ее, написав имя константы. Это подчёркивает неизменность константы, во всём коде.
Примечательное исключение из этого правила, когда константа используется в контексте функции. В этом случае она должна быть написана в camelCase.
// bad const number = 5; // good const NUMBER = 5;
Одна переменная за раз
Каждое объявление локальной переменной объявляет только одну переменную: такие объявления, как let a = 1, b = 2; не используются.
// bad let a = 1, b = 2, c = 3; // good let a = 1; let b = 2; let c = 3;
Используйте одинарные кавычки, а не двойные
Обычные строковые литералы разделяются одинарными кавычками (‘), а не двойными (“).
Совет: если строка содержит символ одинарной кавычки, попробуйте использовать шаблонные строки, чтобы не экранировать кавычки.
// bad
let directive = "No identification of self or mission."
// bad
let saying = 'Say it ain\u0027t so.';
// good
let directive = 'No identification of self or mission.';
// good
let saying = `Say it ain't so`;
Заключительное слово
Как я уже говорил в начале, это не строгие правила. Google, лишь один из многих технологических гигантов, а это только рекомендации.
Тем не менее, интересно ознакомится с рекомендациями по стилю, которые предлагает такая компания, как Google, где работают много блестящих людей, посвятивших уйму времени написанию отличного кода.
Вы можете следовать этим правилам, если хотите быть «Google совместимым разработчиком». Конечно, многие их отвергнут, и вы вправе не согласится с чем то, или даже совсем.
Я лично думаю, что есть много случаев, в которых спецификация Airbnb более привлекательна, чем Google. Независимо от того, какую позицию вы занимаете по этим конкретным правилам, все равно важно иметь в виду стилистическую согласованность при написании любого кода.
Перевод статьи: Daniel Simmons 13 Noteworthy Points from Google’s JavaScript Style Guide
