Google выпускает множество разных руководств для веб-дизайнеров и разработчиков. Это и рекомендации по работе со стилями, иконками, рекомендации по внедрению программного кода и так далее. Не оставили они без внимания и JavaScript, для которого решили создать собственное руководство (и когда еще создать) и рассказать каким они видят чистый, правильный, идеальный код. Руководство достаточно большое, насыщенное и многим разработчикам оно не будет лишним к ознакомлению.
Мы же хотим остановиться в этом материале на некоторых отдельных моментах его и рассмотреть их более подробно. Наши читатели, вероятно, вспомнят, что ранее мы подобный материал размещали и относительно правильности использования и работы в Photoshop в веб-дизайне (этикет). Вот и сейчас нечто подобное вас, читатели, ожидает и о JavaScript.
Мы посмотрим на самые обычные моменты, связанные с кодом: табы, точки с запятыми, типы выравнивания, различные функции, длинные строки и многое lдругое. Но, разумеется, все подробности и еще большее количество интересностей находится в самом руководстве Google.
Разнообразная стилизация
Как ни странно, но не только для визуальных элементов существуют стили. Для программного кода тоже. И у каждого разработчика есть свой, тот, что он пишет, когда не задумывается о существующих руководствах и который зависит от того, как он учился программированию вообще, что читал и видел.
Но если идет работа в команде, то единое для всех руководство нужно всегда. Невозможно солировать в группе и ожидать гармонии. Аналогично и в веб-разработке, и в дизайне, и любой иной деятельности. Но основным вопросом становятся нюансы, мелочи каждого существующего руководства.
Если взять Airbnb, MDN, Google, jQuery JS Style и иные, то в части деталей они разнятся, но и во многом схожи. Так ли уж важно изучать все мелочи, все нюансы каждого руководства? Двоякий ответ. С одной стороны, самому компьютеру или браузеру не столь важно, как оформляется написание кода. Если разумеется, например, лишние пробелы и слеши не вызывают ошибок. Но если создается код, который впоследствии будет редактироваться и, возможно, уже не самим автором – то стиль и четкость, ясность и чистота кода – очень важны.
Сами Google свое руководство начали создавать очень давно, еще 2010 году. И только в 2018 наконец-то завершили и довели до ума. Оно имеет расхождения с иными руководствами, но также есть и общие черты. Это руководство своеобразно и порождает до сих пор множество дискуссий, споров и обсуждений. И это отлично!
Но давайте же приступим и посмотрим на часть того, что предлагают в Google по оформлению кода JS, сравним с другими руководствами.
Точка с запятой
Все предложения, что размещаются на своих строках, должны быть разделены точкой с запятой «;». При этом такие знаки необходимо ставить вручную, а не полагаться на автоматическое завершение строки, что присутствует в разных приложениях в качестве дополнительной упрощающей работу функции.
Да, существуют те разработчики, что до сих пор отказываются использовать точку с запятой, объясняя это тем, что им так нравится или ссылаясь на руководство standardjs.com, но, по мнению Google, чистый код – понятный код. Поэтому такой знак использоваться должен и он обязателен.
Выравнивание по горизонтали не в приоритете
Google очень нейтрально относится к горизонтальному выравниванию. Оно и не поощряется, и оно считается излишним, если оно уже использовалось, то нет смысла еще раз его устанавливать.
Иными словами, суть в том, что Google не считает обязательным, чтобы, например, в начале строки разработчик намеренно выставлял ряд пробелов, а затем писал токен. Потом повторял данное действие на следующей строке, и новый токен появлялся строго под первым токеном.
Скорее, они даже несколько негативно относятся к лишним пробелам. А потому следующее о чем и поговорим – о пробелах.
Забудем о Tab
Единственным пробелом, что будет использоваться во всем программном коде, должен стать обычный пробел, а не Tab. В кодировке ASCII это (0x20). Таким образом, для отступов символы табуляции не должны использоваться вообще.
Также Google уточняет, что при необходимости создавать отступы, пробелов должно быть два, против четырех, что используются в некоторых иных руководствах. Таким образом, перед каждым новым блоком нужно ставить только два пробела, а затем их также закрывать.
Отметим пробелы знаком «+» и тогда варианты чистого кода JS будут выглядеть так:
Забудем о var
Переменные должны обозначаться с помощью let или const. Последнее обычно используется по умолчанию, а первое – при необходимости переназначения переменной. Но var не должно присутствовать.
Удивительно, но факт: открывая все тот же StackOverflow, до сих пор можно видеть примеры кода с использованием var. Но тут уж воля разработчика и специфика ресурса. Хотя есть множество тем с обсуждением того, действительно ли необходимо забыть о var. Так или иначе, но строгого правила нет и привычки могут оставаться, но стараться следовать руководствам все же стоит.
Стрелочные функции нужны и важны
Благодаря стрелочным функциям код можно упростить, исправить некоторые сложности, сделать синтаксис еще более ясным. Поэтому при использовании вложенных функций, лучше отдавать предпочтение не ключевым словам, а именно что стрелочной функции.
Но знаете, они действительно приятны на вид и коротки, а выполняют многое. И это отлично, что Google не отказывается от них!
По сути, все, что мы рассмотрели выше, относилось не только к руководству Google, но и к не менее известному от airbnb. Во многом они схожи, но логично, если были бы полностью схожи, то смысла в одном из них не было совершенно точно. Но вот и некоторые отличия от иных руководств.
Символы продолжения строки и длинные строки
Google рекомендует не использовать символы продолжения строки (например, слеш) при длинных строках. Да, ES5 вполне допускает такое, но вот Google полагает, что это может привести к ошибкам самого разного рода и вида. Особенно если после слеша присутствует пробел.
Что же касается Airbnb, то в пункте 6.2 они рекомендуют оставить строки такими, какие они есть и ничего не предпринимать.
Как поступать самим веб-разработчикам – дело личное. Никто не говорит о том, что нужно только по «этому» руководству все делать или по «воон тому». Поэтому решение за вами.
Забываем о eval
Кроме того, Google весьма отлично поддерживает и рекомендации от Mozilla – MDN. В частности, оба руководства сходятся в том, что ни конструктор Function(…string), ни eval не нужны для загрузчиков кода. Тем более, что они попросту не способны работать в CSP-окружениях.
MDN прямо и громко гласит: eval - опаснейшая функция, выполняющая код, проходящий со всеми привилегиями вызывается. Для общих случаев применения существуют более безопасные и быстрые альтернативы.
Не обошли в Google стороной и ES6. Но тут ситуация получилась двоякая. С одной стороны, они не рекомендуют использовать некоторые спецификации, с другой – описывают ограничения для иных моментов. Итак…
Цикл for хуже for… of
Существует три вида циклов, описанных в ES6. Использоваться в программировании могут все, но Google отдает предпочтение именно «for … of».
Странно решение компании - выделить один цикл из множества. Обычно для каждой задачи использовался «свой» цикл. Например, цикл for... in отлично себя показывал при работе с объектами, а массивы обрабатывались же с помощью for... of.
Но Google решили отдать предпочтение только одному.
Модули ES6
И здесь снова мы видим расхождения у Google и Аirbnb. Первый предостерегает от использования модулей (import/export), так как семантика их еще не завершена и не получила окончательной стандартизации. Второй же наоборот, призывает к этому.
Завершение
Любое руководство по стилю в веб-дизайне или веб-разработке – не строгие правила и аксиомы. Это именно – руководство к действиям, рекомендации. Другое дело – кто автор такого руководства. Было бы оно написано кем-то малоизвестным, возможно, на него мало обращали внимания. Но такой гигант, как Google, разумеется, привлекает к своей работе внимание.
И это с учетом того, что они также написали свои рекомендации и по стилям C++, HTML/CSS, AngularJS, Vimscript и прочему, и прочему. А это значит только то, что люди, большое количество времени проводящие за написанием разного программного кода, действительно способны разобраться и в нем, и его оформлении. В том, каким его лучше создавать, чтобы он был удобен всегда и всем.
Но никто не запрещает совмещать разные руководства, выбирать из одного часть методик, из другого советы. И таким образом создавать уже свой собственный стиль, который, возможно, будет удобен только вам или вашей команде. И это приветствуется зачастую даже больше, чем строгое и скрупулезное следование чему-то одному. Но для этого нужна очень большая практика.
Если реально сравнивать два крупнейших и известных руководства (Airbnb и Google), то спецификации первого многими воспринимаются теплее и дружественнее, чем варианты Google. Но так или иначе – все это личный опыт и решение каждого разработчика в отдельности. Другое дело, решая выборочно придерживаться каких-либо рекомендаций нужно сохранять и целость стилистики. Выбрали пробелы вместо Tab, значит, везде пробелы, а не кусочками, то тут, то там. Решили отказаться от слешей, значит, отказ на протяжении всего проекта.