13 забележителни точки от ръководството на Google за стил на Google

За всеки, който още не е запознат с него, Google издава ръководство за стил за писане на JavaScript, което излага (това, което Google смята), най-добрите стилистични практики за писане на чист, разбираем код.

Това не са строги правила за писане на валиден JavaScript, а само проскрипции за поддържане на последователен и привлекателен избор на стил във всичките ви изходни файлове. Това е особено интересно за JavaScript, който е гъвкав и прощаващ език, който позволява голямо разнообразие от стилистични решения.

Google и Airbnb имат два от най-популярните ръководства за стил там. Определено бих препоръчал да разгледате и двамата, ако прекарвате много време в писане на JS.

По-долу са дадени тринадесет от най-интересните и подходящи според мен правила от ръководството на JS за стила на Google.

Те се занимават с всичко, от горещо оспорвани проблеми (табулатори срещу интервали и спорния въпрос за начина, по който трябва да се използват точки и запетая), до още няколко неясни спецификации, които ме изненадаха. Те определено ще променят начина, по който пиша своя JS занапред.

За всяко правило ще дам обобщение на спецификацията, последвано от подкрепящ цитат от ръководството за стил, който подробно описва правилото. Където е приложимо, ще дам и пример за стила на практика и ще го сравня с код, който не спазва правилото.

Използвайте интервали, а не раздели

Освен последователността на крайния ред, ASCII символът за хоризонтално интервал (0x20) е единственият пробел, който се появява навсякъде в изходен файл. Това предполага, че ... Символите на табулатора не се използват за отстъп.

По-късно ръководството посочва, че трябва да използвате две интервали (а не четири) за отстъп.

// badfunction foo() {∙∙∙∙let name;}// badfunction bar() {∙let name;}// goodfunction baz() {∙∙let name;}

Точки и запетая СА ИЗИСКВАНИ

Всяко изявление трябва да бъде прекратено с точка и запетая. Разчитането на автоматично вмъкване на точка и запетая е забранено.

Въпреки че не мога да си представя защо някой се противопоставя на тази идея, последователното използване на точка и запетая в JS се превръща в новия дебат „интервали срещу табулатори“. Google излиза твърдо тук в защита на запетая.

// badlet luke = {}let leia = {}[luke, leia].forEach(jedi => jedi.father = 'vader')
// goodlet luke = {};let leia = {};[luke, leia].forEach((jedi) => { jedi.father = 'vader';});

Не използвайте ES6 модули (все още)

Все още не използвайте ES6 модули (т.е. the 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 Style. Дори не се изисква да се поддържа хоризонтално подравняване на места, където вече е било използвано.

Хоризонталното подравняване е практиката на добавяне на променлив брой допълнителни интервали във вашия код, за да се появят определени маркери директно под определени други символи на предишни редове.

// bad{ tiny: 42, longer: 435, };
// good{ tiny: 42, longer: 435,};

Не използвайте вече var

Декларирайте всички локални променливи с constили let. Използвайте const по подразбиране, освен ако променлива трябва да бъде преназначена. В varне трябва да се използва ключовата дума.

Все още виждам хора, използващи varв примерни кодове на StackOverflow и другаде. Не мога да разбера дали има хора там, които ще докажат това, или това е просто случай на стари навици, умиращи трудно.

// badvar example = 42;
// goodlet example = 42;

Предпочитат се функциите със стрелки

Функциите със стрелки осигуряват кратък синтаксис и решават редица трудности this. Предпочитайте функциите със стрелки пред 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;});

Използвайте низове на шаблони вместо конкатенация

Използвайте низове на шаблони (разграничени с `) за сложна конкатенация на низове, особено ако са включени множество низови литерали. Низовете на шаблона могат да обхващат няколко реда.
// badfunction sayHi(name) { return 'How are you, ' + name + '?';}// badfunction sayHi(name) { return ['How are you, ', name, '?'].join();}// badfunction sayHi(name) { return `How are you, ${ name }?`;}// goodfunction 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.';
// goodconst 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.';

„За ... на“ е предпочитаният тип „за цикъл“

С ES6 езикът вече има три различни вида forцикли. Може да се използват всички for- ofцикли трябва да се предпочитат, когато е възможно.

Това е странно, ако питате мен, но реших, че ще го включа, защото е доста интересно, че Google декларира предпочитан тип forцикъл.

Винаги бях с впечатлението, че for... inконтурите са по-добри за обекти, докато for... ofса по-подходящи за масиви. „Правилен инструмент за подходящата работа“.

Въпреки че спецификацията на Google тук не противоречи непременно на тази идея, все пак е интересно да се знае, че те предпочитат именно този цикъл.

Не използвайте eval ()

Не използвайте evalили Function(...string)конструктора (с изключение на зареждащите кодове). Тези функции са потенциално опасни и просто не работят в CSP среди.

Страницата MDN за eval()дори има раздел, наречен „Не използвайте 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

Константите трябва да бъдат назовавани във ALL_UPPERCASE, разделени с долни черти

Постоянни имена използват CONSTANT_CASE: всички главни букви, с думи, разделени с долни черти.

Ако сте абсолютно сигурни, че дадена променлива не трябва да се променя, можете да посочите това, като пишете името на константата с главни букви. Това прави неизменността на константата очевидна, тъй като тя се използва в целия ви код.

Забележително изключение от това правило е, ако константата е с функционен обхват. В този случай трябва да се напише в camelCase.

// badconst number = 5;
// goodconst NUMBER = 5;

Една променлива на декларация

Всяка декларация на локална променлива декларира само една променлива: декларации като let a = 1, b = 2;не се използват.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;

Използвайте единични кавички, а не двойни кавички

Обикновените литерални низове се разграничават с единични кавички ( '), а не с двойни кавички ( "). Съвет: ако низ съдържа единичен знак за кавички, помислете за използването на шаблонния низ, за ​​да избегнете избягването на цитата.
// badlet directive = "No identification of self or mission."
// badlet saying = 'Say it ain\u0027t so.';
// goodlet directive = 'No identification of self or mission.';
// goodlet saying = `Say it ain't so`;

Последна бележка

Както казах в началото, това не са мандати. Google е само един от многото технологични гиганти и това са само препоръки.

Въпреки това, интересно е да разгледаме препоръките за стил, публикувани от компания като Google, в която работят много брилянтни хора, които прекарват много време в писане на отличен код.

You can follow these rules if you want to follow the guidelines for ‘Google compliant source code’ — but, of course, plenty of people disagree, and you’re free to brush any or all of this off.

I personally think there are plenty of cases where Airbnb’s spec is more appealing than Google’s. No matter the stance you take on these particular rules, it is still important to keep stylistic consistency in mind when write any sort of code.