Перевод статьи Дэниела Симмонса «Google publishes a JavaScript style guide. Here are some key lessons».
Для тех, кто еще не в курсе: Google выпустил руководство по стилю кода JavaScript, которое (по мнению Google) должно стать дорожной картой с лучшими стилистическими подходами для написания чистого, понятного кода.
Это не жесткие и неукоснительные правила написания валидного JavaScript-кода. Это скорее рекомендации придерживаться последовательного и приемлемого стиля во всех файлах исходного кода. Это особенно интересно в отношении JavaScript, поскольку это гибкий и “снисходительный” язык, допускающий широкое разнообразие вариантов стиля.
Google и Airbnb выпустили два самых популярных руководства по стилю. Я бы рекомендовал вам просмотреть оба, если вы проводите много времени за написанием кода JS.
Следующие тринадцать пунктов содержат рекомендации, которые я счел самыми интересными в руководстве Google.
Они касаются всего, от вопросов, вызывающих горячие споры (табы и пробелы, обязательность точки с запятой), до нескольких непонятных спецификаций, которые меня удивили. Эти рекомендации определенно изменят мой подход к написанию кода JS в дальнейшем.
Для каждого правила я привожу краткое описание спецификации, за которым следует более подробное в цитате из руководства по стилю. Там, где это уместно, я также приведу пример применения указанного стиля в контрасте с кодом, не соответствующим рекомендациям.
Используйте пробелы, а не табы
Помимо перевода строки, горизонтальный символ пробела (0x20) ASCII это единственный пробельный символ, используемый в файле исходного кода. Это означает, что символы табуляции не используются для отступов.
Позже в руководстве уточняется, что для создания отступов следует использовать два пробела (не четыре).
// bad
function foo() {
∙∙∙∙let name;
}
// bad
function bar() {
∙let name;
}
// good
function baz() {
∙∙let name;
}
Точки с запятыми обязательны
Каждое предложение должно отделяться точкой с запятой. Полагаться на автоматическую вставку точек с запятыми запрещается.
Я не могу представить, почему кто-то противится этой идее, но последовательное использование точек с запятыми в JS становится новым спорным моментом наравне с «пробелами против табов». В этом вопросе 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 (например, ключевые слова export и import), поскольку их семантика еще не завершена. Имейте в виду, что это правило будет пересмотрено, как только семантика станет полностью стандартизированной.
// 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 не должно использоваться.
Я все еще вижу, что люди пользуются var в примерах кода на StackOverflow и других сайтах. Не могу сказать, имеет ли это для них большое значение или это просто старая привычка, от которой тяжело избавиться.
// bad var example = 42; // good let example = 42;
Стрелочные функции предпочтительны
Стрелочные функции придают краткость синтаксису и исправляют многие сложности, с ним связанные. Отдавайте предпочтение стрелочным функциям, а не ключевым словам, особенно для вложенных функций.
Честно говоря, я думал, что главное достоинство стрелочных функций в краткости и более приятном виде. Оказалось, что они также имеют достаточно важное назначение.
// 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}?`;
}
Не используйте символов продолжения строки для длинных строк
Не используйте символы продолжения строки (т. е., обратный слэш для окончания строки внутри строкового литерала) как в обычных,так и в шаблонных строковых литералах. Несмотря на то что 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-of, если это возможно.
Как по мне, это странно, но я решил включить этот пункт, поскольку интересен сам факт, что Google отдает предпочтение определенному виду циклов.
Мне всегда казалось, что циклы for... in лучше для объектов, а for... of больше подходят для массивов. Ситуация в стиле «свой инструмент для каждой работы».
Хотя спецификация Google не обязательно противоречит этой идее, все равно интересно знать, что они отдают предпочтение именно этому виду циклов.
Не используйте eval()
Не используйте eval или конструктор Function(…string), особенно для загрузчиков кода. Эти свойства являются потенциально опасными и попросту не работают в CSP-окружениях.
Страница MDN, посвященная eval(), даже содержит раздел под названием «Не используйте eval!».
// bad
let obj = { a: 20, b: 30 };
let propName = getPropName(); // returns "a" or "b"
eval( 'var result = obj.' + propName );
// good
let obj = { a: 20, b: 30 };
let propName = getPropName(); // returns "a" or "b"
let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a
Константы должны именоваться только заглавными буквами, с разделителем в виде подчеркивания
Имена констант используют CONSTANT_CASE: все буквы прописные, слова разделяются символом подчеркивания.
Если вы абсолютно уверены, что переменная не должна меняться, вы можете обозначить это, написав ее имя только заглавными буквами. Это делает неизменность константы очевидной, где бы в вашем коде она не использовалась
В этом правиле есть исключение: константа, ограниченная областью функции. В этом случае ее имя должно писаться в 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. И независимо от того, решите вы соблюдать эти конкретные правила или нет, очень важно при написании любого вида кода придерживаться стилистической последовательности.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
