Для тех кто еще не в курсе, Google выложил стилевое руководство по написанию JavaScript, которое излагает лучшие стилистические практики по написанию ясного и понимаемого кода.
\n\n\n\n\n\n\n\nТам нет строгих правил для написания валидного JavaScript, а есть только советы для написания последовательного и привлекательного кода для всех ваших проектов. Особенно это интересно для JavaScript, который сам по себе гибкий и довольно многообразный язык, позволяющий использовать широкий выбор стилизации кода.
\n\n\n\nУ Google и Airbnb есть два самых популярных стилевых руководства по этой теме. Я определенно советую вам ознакомится с обоими, если вы проводите много времени с JavaScript.
\n\n\n\nДалее в статье будут тринадцать самых интересных замечаний и релевантных правил из Google JS Style Guide.
\n\n\n\nОни покрывают весь спектр работы с кодом, от спорных вопросов до неясных спецификакций, которые удивили даже меня. Конечно же, они изменят суть того, как я буду писать JavaScript в будущем.
\n\n\n\nДля каждого правила я дам краткое изложение по спецификации, подкрепленное цитатой из стилевого руководства, которое описывает правило в деталях. Где это будет возможно, я покажу пример стиля на практике и сопоставлю его с кодом, который не подходит этому правилу.
\n\n\n\n\n\n\n\nКроме символа разграничителя строки, ASCII символ горизонтального пробела (0х20) — единственный символ пробела/разграничителя, который появляется где-либо в исходном файле. Это подразумевает то, что Tab символы не используются для отступов.
// плохо\nfunction foo() {\n∙∙∙∙let name;\n}\n\n// плохо\nfunction bar() {\n∙let name;\n}\n\n// хорошо\nfunction baz() {\n∙∙let name;\n}\n\n\n\nКаждое объявление должно заканчиваться на точку с запятой.
Запрещается полагаться на автоматическую вставку этих символов.
Хоть я и не могу представить, почему кто-то против этой идеи, но использование точек с запятыми в JS становится новыми дебатами масштаба ‘spaces versus tabs’.
\n\n\n\nGoogle твердо обозначил свою позицию в защиту использования точки с запятой.
\n\n\n\n// плохо\nlet luke = {}\nlet leia = {}\n[luke, leia].forEach(jedi => jedi.father = 'vader')\n\n// хорошо\nlet luke = {};\nlet leia = {};\n[luke, leia].forEach((jedi) => {\n jedi.father = 'vader';\n});\n\n\n\nНе применяйте модули из ES6, пока что (т.е. слова export и import), так как их семантика пока не не финализирована. Обратите внимание, что это правило будет пересмотрено, после того, как семантика станет полным стандартом.
// Не делайте пока что такие вещи:\n// — — — lib.js — — —\nexport function square(x) {\n return x * x\n}\nexport function diag(x, y) {\nreturn sqrt(square(x) + square(y));\n}\n//------ main.js ------\nimport { square, diag } from 'lib';\n\n\n\nЭта практика допустима, но в основном это считается дурным тоном следуя стилю от Google. Не нужно даже продолжать использовать горизонтальные выравнивания в местах, где это уже использовалось.
Горизонтальное выравнивание это практика добавления большого количества пробелов в ваш код, чтобы определенные символы появлялись прямо под другими символами на предыдущей строке.
\n\n\n\n// плохо\n{\n tiny: 42, \n longer: 435, \n };\n // хорошо\n {\n tiny: 42, \n longer: 435,\n };\n\n\n\nОбъявляйте все локальные переменные с помощью const или let. Используйте const по дефолту, пока переменную не надо будет переназначить. Слово var не должно использоваться.
Я до сих пор вижу людей, которые используют слово var в примерах кода. Не могу сказать, есть ли для этого веские причины или это просто дело долгоумерающей привычки.
// плохо\nvar example = 42;\n// хорошо\nlet example = 42;\n\n\n\nСтрелочные функции дают краткий синтаксис и решают много сложностей с ним. Предпочитайте стрелочные функции вместо слова function, особенно во вложенных функциях.
Буду честен, я просто думал, что стрелочные функции это отлично, потому что они короче и вообще лучше выглядят. Но оказывается, что у них довольно важное предназначение в плане упрощения написания кода.
\n\n\n\n// плохо\n[1, 2, 3].map(function (x) {\n const y = x + 1;\n return x * y;\n});\n\n// хорошо\n[1, 2, 3].map((x) => {\n const y = x + 1;\n return x * y;\n});\n\n\n\nИспользуйте шаблонные строки, обозначемые с помощью `, вместо сложного объединнения строк, особенно если есть несколько строчных литералов. К тому же, они могут быть в несколько строк.
// плохо\nfunction sayHi(name) {\n return 'How are you, ' + name + '?';\n}\n\n// плохо\nfunction sayHi(name) {\n return ['How are you, ', name, '?'].join();\n}\n\n// плохо\nfunction sayHi(name) {\n return `How are you, ${ name }?`;\n}\n\n// хорошо\nfunction sayHi(name) {\n return `How are you, ${name}?`;\n}\n\n\n\nНе применяйте line continuations как в обычных строках, так и в шаблонных строках. Пусть даже ES5 позволяет делать это, такой подход может привести с неловким ошибкам, если какой-нибудь пробел будет после слеша и это менее очевидно для читателей.
Интересен тот момент, что это правило по которому мнения Google и Airbnb расходятся. Вот пример Airbnb.
\n\n\n\nВ то время, как Google рекомендует связывать длинные строки, как показано ниже, руководство от Airbnb советует буквально ничего не делать и допускать длинным строкам тянуться сколько хотят.
\n\n\n\n// Плохо (Извините, это не показывается как надо на мобильных)\nconst longString = 'This is a very long string that \\\n far exceeds the 80 column limit. It unfortunately \\\n contains long stretches of spaces due to how the \\\n continued lines are indented.';\n// Хорошо\nconst longString = 'This is a very long string that ' + \n 'far exceeds the 80 column limit. It does not contain ' + \n 'long stretches of spaces since the concatenated ' +\n 'strings are cleaner.';\n\n\n\nВ ES6, у языка теперь три разных типа циклов for. Их все можно использовать, хотя for-of циклы должны быть предпочтительнее, если возможно.
Это странно, если вы спросите меня, но я думаю это надо упомянуть, так как довольно интересно, что Google объявил предпочтительный тип цикла loop.
\n\n\n\nЯ был всегда впечатлен тем, что for…in циклы были лучше для объектов, в то время как for…of были лучше для массивов. В общем правильный инструмент для подходящей ситуации.
Пока спецификация Google не противоречит этой идее, до сих пор интересно узнать, почему они сделали предпочтение в сторону этого цикла.
\n\n\n\n\n\n\n\nНе используйте eval или Function(…string) конструктор, кроме кодлоадеров. Этот функционал потенциально опасен и просто не работает в CSP среде.
На страничке eval() в MDN, даже есть секция под названием “Не используйте eval!”
// плохо\nlet obj = { a: 20, b: 30 };\nlet propName = getPropName(); // returns \"a\" or \"b\"\neval( 'var result = obj.' + propName );\n\n// хорошо\nlet obj = { a: 20, b: 30 };\nlet propName = getPropName(); // returns \"a\" or \"b\"\nlet result = obj[ propName ]; // obj[ \"a\" ] is the same as obj.a\n\n\n\nЕсли вы уверены в том, что какие-либо переменные не должны меняться, вы можете указать это написав имя переменной с большой буквы. Это сделает неизменность константы очевидной, как только она начнет использоваться по всему коду.
НО есть примечательное исключение для этого случая, это константы в функциях. Тут они должны писаться камелКейсом или по-русски горбатым регистром.
\n\n\n\n// Плохо\nconst number = 5;\n// Хорошо\nconst NUMBER = 5;\n\n\n\nКаждая локальная переменная объявляет только одну переменную: такие объявления как let a = 1, b =2 не используются.
// bad\nlet a = 1, b = 2, c = 3;\n// good\nlet a = 1;\nlet b = 2;\nlet c = 3;\n\n\n\nОбычные строчные литералы заключаются в одинарные кавычки, а не в двойные.
Совет: если строка содержит один символ цитирования, то рассмотрите использование шаблонных строк во избежании выхода из области цитаты.
\n\n\n\n// плохо\nlet directive = \"No identification of self or mission.\"\n// плохо\nlet saying = \n'Say it ain\\u0027t so.';\n// хорошо\nlet directive = 'No identification of self or mission.';\n// хорошо\nlet saying = `Say it ain't so`;Как я и сказал вначале, это не строгие правила. Google это просто один из технологических гигантов и это просто рекомендации.
\n\n\n\nИнтересно посмотреть на стиль рекомендаций, которые выкладывают компании, такие как Google, которые нанимают множество блестящих людей, которые тратят непомерно много времени на написание отличного кода.
\n\n\n\nВы можете следовать этим правилам, если хотите. Но всегда будут недовольные и вы спокойно можете пренебречь некоторыми или вообще всеми из этих правил.
\n\n\n\nЯ лично считаю, что есть несколько случаев, в которых спецификации Airbnb более подходящи, чем от Google. Не важно какую позицию вы занимаете по этим конкретным правилам, все ещё важно соблюдать стилистическую последовательность при написании любого кода.
\n","type":"js","date":"2020-08-17T14:14:10.000Z","acf":{"seo_desc":"Тринадцать самых интересных замечаний и релевантных правил из Google JS Style Guide","keywords":"Google Style Guide, стилизация кода, правила стилизации кода, код JavaScript","pub_date":"2018-06-14","tags":"JavaScript, JavaScript советы"},"title":"13 интересных моментов по стилизации JavaScript кода от Google","id":"9624dab4-aa17-5129-835c-f320b0ba8e95","excerpt":"Для тех кто еще не в курсе, Google выложил стилевое руководство по написанию JavaScript, которое излагает лучшие стилистические практики по написанию ясного и понимаего кода.
\n","featured_media":{"source_url":"https://stasonmars.ru/wp/wp-content/uploads/2020/08/DglYtvO7Bn0.jpg"},"interesting":[{"title":"Замыкающие запятые (Trailing Commas) в JavaScript ES 2017","slug":"trailing-commas-v-javascript-es-2017","type":"js"},{"title":"13 интересных моментов по стилизации JavaScript кода от Google","slug":"13-interesnih-momentov-po-stilizacii-koda-ot-google","type":"js"},{"title":"Методы JavaScript, которые улучшат ваши умения за несколько минут","slug":"metody-javascript-kotorie-uluchshat-vashi-umenia-za-neskolko-minut","type":"js"}]}},"staticQueryHashes":["3576131997","63159454"]}