13 интересных моментов из руководства по стилям для JavaScript от Google +16



Для тех, кто еще не видел: Google опубликовал руководство по стилям для JavaScript, где изложены лучшие стилистические практики (по версии компании) для написания аккуратного, понятного кода.


Это не жесткий свод правил для грамотного программирования на JavaScript, а просто набор ограничений, чтобы выдерживать единую привлекательную стилистику во всех исходных файлах. Для JavaScript подобное руководство представляет особенный интерес — это очень гибкий и нетребовательный язык, который дает значительный простор для выбора.

Самые популярные руководства по стилю — те, которые предложили Google и Airbnb. Если вы много времени проводите за работой с JS, рекомендую ознакомиться с обоими. Ниже я приведу тринадцать правил из руководства Google, которые показались мне особенно интересными. Оно затрагивает все: и камни преткновения, которые вызывают больше всего споров (пробелы против табуляции, дискуссионный вопрос о том, как использовать точки с запятой), так и некоторые менее обсуждаемые моменты, которые меня удивили. Все это определенно повлияет на мои практики написания кода в будущем.

Для каждого правила я буду приводить краткое изложение требования, цитату из руководства, где оно формулируется более подробно, а также, по возможности, примеры его применения вместе с фрагментами, где оно нарушается, чтобы можно было сравнить.

Используйте пробелы, а не табуляцию


За исключением символов переноса строки, пробел в ASCII (0x20) — единственный символ, который должен появляться в исходных файлах для обозначения отступа. Это подразумевает, что… табуляция не применяется для форматирования.

Позже в руководстве также уточняется, что для отступа следует ставить два пробела, а не четыре.

// 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 (например, для экспорта и импорта ключевых слов), так как их семантика еще не приобрела окончательный вид. Отметим, что это правило будет пересмотрено, когда семантика будет окончательно приведена к стандарту.

// 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;

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


Стрелочные функции обеспечивают лаконичный синтаксис и тем самым разрешают ряд сложностей. Отдавайте предпочтение им, а не ключевым словам для функций, особенно если речь идет о вложенных функциях.

Скажу честно: мне стрелочные функции нравятся просто потому, что они смотрятся лучше и аккуратнее. Но, как выясняется, они еще и служат довольно важной цели.

// 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}?`;
}

Не используйте продолжение строки для длинных строк


Не используйте продолжение строки (иными словами, не завершайте строку в составе строкового литерала символом бэкслэша) ни в обычных строковых литералах, ни в литералах шаблона.

Что интересно, здесь Google расходится во мнениях с 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… 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

Константы должны записывать КАПСЛОКОМ и разделяться нижними подчеркиваниями


Названия констант прописываются в особом формате: заглавными буквами и с нижними подчеркиваниями между отдельными словами.

Если вы совершенно уверены, что переменная должна оставаться неизменной, можно подчеркнуть это, прописывая ее название заглавными буквами. Так читающему код будет сразу понятно, что переменная неприкосновенна, в каком бы фрагменте она ему ни встретилась.

Важное исключение из этого правила составляют константы в пределах функции. В их случае следует использовать верблюжий регистр.

// 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, есть и другие IT гиганты, да и правила эти носят скорее рекомендательный характер.

Но даже с этой оговоркой, рекомендации по стилю от такой компании, как Google, у которой множество талантливых сотрудников, пишущих отличный код, вызывают немалый интерес. Вы можете придерживаться этих правил, если хотите писать «исходный код, совместимый с продуктами Google», а можете просто махнуть на них рукой.

Лично мне кажется, что спецификации Airbnb во многих отношениях привлекательнее, чем у Google. Но какую бы позицию вы не заняли по отношению к этим правилам, важно помнить одно: при работе над любым кодом в стилистике должно выдерживаться постоянство.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (96):

  1. Sirion
    /#11359504 / +3

    Сколько лет живу, никак не могу понять, чем пробелы лучше табов.

    • MzMz
      /#11359514

      Код выглядит одинаково в любом редакторе и консоли

      • Sirion
        /#11359516 / +2

        А почему это достоинство? Нормальные редакторы позволяют настроить ширину таба под себя. Кому-то комфортнее читать код с широкими отступами, кому-то с узкими.

        • Zagrebelion
          /#11359526

          Табы в этом смысле лучше, но только в том случае, если у всей команды настроено одинаково. Достаточно найтись одному чудику, у которого редактор заменяет табы на пробелы, и вся гибкость ломается.

          • Sirion
            /#11359570

            Ну, стайл гайды — это в принципе о том, чтобы у команды всё было настроено одинаково.

        • MacIn
          /#11360202

          Вы можете читать/модифицировать в одном редакторе коды разных проектов без перенастройки.

        • VolCh
          /#11360418 / +2

          С табами практически невозможно контролировать длину строки. Я поставлю таб на 1 пробел и сделаю 70 отступов.

          • urrri
            /#11360446

            Первое логичное объяснение

        • untilx
          /#11360902

          Нормальные редакторы распознают тип отступа и позволяют настраивать его ширину независимо от того, что на самом деле используется. Другое дело, что не все их используют. Но возможность эта тоже востребована мало, тем более, что просто разная настройка ширины одного и того же отступа иногда превращает код в кашу (например, грепом или диффом в консоли посмотреть), особенно, если вдруг найдётся какой-нибудь любитель горизонтального выравнивания.

    • minamoto
      /#11359572

      Я только недавно наткнулся на эпичные посты, касающиеся обсуждения этой проблемы:
      первый: habr.com/company/pvs-studio/blog/118204
      и ответ на него: habr.com/post/118208
      Если еще не читали, рекомендую. В статьях и комментариях разобрано большое количество причин предпочесть одно другому, и в каких случаях какой способ предпочтительнее

      • Sirion
        /#11359590 / +1

        Именно о таком ответе я втайне молился. Спасибо вам большое, добрый человек. (Не ирония)

    • sanchezzzhak
      /#11361062

      Пробелы легче контролировать в консольной ide, хотя за такое по рукам надо бить за правки на сервере.

      • c4boomb
        /#11361174

        Вы думаете никто не использует Vim как основную иде?

        • sanchezzzhak
          /#11361910

          Используют, вот что лучше проще проставить в vim пробелы или таб, это без знания команд

  2. paratagas
    /#11359542 / +1

    Странно, что для перебора массивов предпочтение отдается циклу for...of, а не Array.prototype.forEach, в котором из коробки есть доступ к индексу элемента массива. Еще смущает объявление всех переменных в одном месте. А как же быть с правилом — объявлять переменную поближе к месту использования? Кроме того, не особо удобно рефакторить. В названном «плохим» варианте удаление или закоментирование строки не влияет на другой код. В «хорошем» варианте нужно вырезать из середины объявления, следить за запятыми и точкой с запятой в конце выражения (если удаляется последняя переменная списка). Также не понимаю преимуществ одинарных кавычек. Например в повсеместно используемом формате JSON используются как раз-таки только двойные кавычки. Почему для JS формата дожно быть по другому?

    • Gentlee
      /#11359576

      Для forEach ты создаёшь функцию, для for...of — нет. Значит он работает быстрее.


      По поводу ‘ и « — код чем короче, тем лучше (при прочих равных). Двойные ковычки занимают в два раза больше места.

      • Sirion
        /#11359592 / +6

        Двойные ковычки занимают в два раза больше места.

        У вас в редакторе шрифт не моноспейс? Месье знает толк в извращениях.

        • Gentlee
          /#11359708 / -1

          В моем редакторе да, но не все в мире отображается в моем редакторе. И даже в моноспейсе — площадь самого шрифта двойной кавычки в два раза больше, это выглядит «грязнее» и «тяжелее». Лично мое мнение.

      • paratagas
        /#11359618 / +1

        Согласен насчет того, что без функции работает быстрее. С другой стороны, удобство функции в том, что ее можно создать единожды и передавать в forEach для обработки разных массивов. С for...of придется повторять весь цикл заново для каждого массива.

        • hahenty
          /#11359962

          Сам цикл оформить в функцию, в определённых рамках, конечно же.

      • ReklatsMasters
        /#11359702 / +1

        Скорость работы зависит исключительно от возможностей движка, а не от количества функций.

      • bingo347
        /#11360724

        У for...of под капотом вызов метода под ключом Symbol.iterator на старте и вызов метода next полученого итератора на каждой итерации, так что он не дешевле в плане вызовов.
        кроме того, если понадобится поддержка старья — понадобятся и полифил для Symbol (по крайней мере с тем, что генерит из for...of babel)

      • neurocore
        /#11360816

        Одинарные кавычки в js (и в css тоже), — чтобы при внедрении в html не нужно было эти кавычки экранировать. В html существует негласное соглашение атрибуты заключать в двойные кавычки (хотя одинарные не запрещены).

        • VolCh
          /#11361066

          Тогда достаточно было бы только одинарных:) Скорее два типа идентичных по функциональности кавычек для гибкости. грубо, если в html дввойные, то используем одинарные и наоборот.

          • neurocore
            /#11361352

            Для js, css, html? Тогда нужно экранировать, а это лишние символы.

      • DarthVictor
        /#11361150

        Не обязательно.
        Слева Firefox60, справа Chrome68
        image

    • hubhito
      /#11359684 / +1

      для forEach нет break

      • White_Scorpion
        /#11359748 / -1

        А return — разве не подходит?

        • Akuma
          /#11359994

          Нет, он не прерывает «цикл».
          Есть извращенные способы с try/catch или можно использовать every (но я никогда не пробовал).

          • White_Scorpion
            /#11360016

            Да я уже вкурил, что лажанул с предположением. Разве что через глобальную переменную, проверяемую в начале функции можно его прервать. По принципу: "if (globalToExit) return;" Но это костыль, а не решение.

            • hubhito
              /#11360116

              forEach в любом случае отработает все элементы итерируемого объекта. Если есть, например, массив из нескольких тысяч элементов и нужно сделать поиск по нему то незачем проходить по остальным элементам если нужный уже найден.

              • urrri
                /#11360450

                Дык есть же find()

                • hubhito
                  /#11360476

                  Я привёл поиск только как наиболее понятный пример. Есть огромное количество задач при которых нужно иметь возможность остановить итерирование.

                  • urrri
                    /#11360486

                    Это понятно. Просто есть стандартный набор паттернов, пришедший из Функционального Программирования, который покрывает практически любые варианты. То есть практически льбой цикл можно превратить в последовательность вызовов этих паттернов. Это будет не всегда самое, быстрое, но почти всегда самое читабельное решение (после небольшой практики — вначале и сам страдал)

                    • VolCh
                      /#11361074

                      Скорее не повторить, а обернуть, ведь капотом декларативных методов старые добрые императивные конструкции. По крайней мере пока доминирующими являются императивные платформы типа intel или arm

                    • hubhito
                      /#11361756

                      согласен, но пока нет «ленивых вычислений» и нормальной оптимизации этих функций в javascript движках старый добрый for остаётся рабочей лошадкой.

                      • urrri
                        /#11362186

                        А как же RxJs? Он как раз очень ленивый и предоставляет тот-же стандартный набор

                  • mayorovp
                    /#11361190

                    Для итерации с остановкой можно использовать every или some. Но, как мне кажется, такое допустимо только в WO-однострочниках.

                    • hubhito
                      /#11361766

                      Согласен, я сам пользуюсь там где не так критична скорость. Но пока не будет нормальных «ленивых вычислений» чтобы можно было устанавливать диапазоны/фильтры без пересоздания массива в большинстве реальных ситуаций старый добрый for всё еще является тяговой лошадкой.

    • ReklatsMasters
      /#11359710

      В данном треде обсуждаются исключительно циклы for of, for;; и for in. Среди них предпочтение отдаётся именно первому. А вот для массивов конечно предпочтительнее использовать forEach, map и т.д. У них в спеке это и описано, просто переводчик не уточнил.

    • jacob1237
      /#11361236

      Ничего странного. В Array.prototype.forEach нет возможности использовать break, в то время как в обычных for/while циклах всегда можно. К тому же forEach требует объявления анонимной функции, что не всегда подходит.


      PS. Опоздал, кажется тут уже ответили =)

  3. argonavtt
    /#11359558

    Привычка писать "" вместо '', ни когда не понимал в чём тут подвох. По мне так код с "" выглядит красивее.

    • Sirion
      /#11359566

      У меня осталась привычка от Си. Рационального обоснования ей дать не могу, возможно, от неё действительно стоит избавиться.

    • ReklatsMasters
      /#11359696 / -1

      Преимущество одинарных кавычек в том, что они не обрабатывают спецсимволы. Например, если в двойных кавычках написать \t, он превратится в таб. Начинающие разработчики могут не знать о таком поведении.

      • k12th
        /#11359732 / +2

        Насколько мне известное, такое поведение свойственно PHP, а отнюдь не JS.

        • ReklatsMasters
          /#11359772

          Да, вы правы. Надо было проверить, а не жить в иллюзиях.

          • k12th
            /#11359780

            Всякое случается.
            Будучи начинающим разработчиком, я в 2008 сильно удивил людей на собеседовании в Яндекс, с апломбом заявив, что return в JS не обязателен, из функции вернется последнее вычисленное значение (перепутал уже даже не помню с чем, с Ruby? CoffeScript тогда еще не было). Даже сумел их убедить и они обещали попробовать. В итоге меня даже взяли.
            Молод был, горяч.

            • Sirion
              /#11359792

              С eval, может быть?

              • k12th
                /#11359798

                Не уверен. Кажется, всё-таки думал про Ruby (он как раз тогда набирал популярность).

                • Akuma
                  /#11360020 / +1

                  Поидее можно плагин для babel сделать, который будет эмулировать такое поведение :)
                  Хотя это на грани психбольницы конечно ))

                  • k12th
                    /#11360034

                    Это всё-таки очень не для всех фича, в том же ruby как минимум некоторые разработчики рекомендуют ставить явный return.
                    Это оправданно в lisp-ах, где всё является выражением, ну так можно на scala.js писать, если так уж хочется:)

                    • k12th
                      /#11360566

                      Тьфу ты, closure, конечно, а не Scala.

            • mayorovp
              /#11361198

              А это даже в стандарте прописано. Только есть маленькая деталь: вычисляемый таким образом результат выполнения блока кода не возвращается из функции :-)

              • k12th
                /#11361214

                Простите, не понял вас: что же именно прописано в стандарте? Неявного return из функций там не было последний раз когда я смотрел. Я не про оператор ,, если что.

      • Sirion
        /#11359738 / +1

        Да о таком поведении и заканчивающие разработчики не знают. Потому что это неправда.

    • urrri
      /#11360458

      Когда-то мне объяснили, что в HTML приняты двойные кавычки, и, чтоб писать шаблоны внутри JS удобно использовать одинарные. Действительно было удобно с Ангуларом. В Реакте все равно, но уже привык.

  4. vlreshet
    /#11359604 / +1

    Горизонтальное выравнивание — чем оно им не угодило? ИМХО, с ним код выглядит куда красивее, как-то структурнее что-ли.

    • k12th
      /#11359682 / +1

      Потому что как только вы добавляете в объект новый ключ, вам надо заново форматировать весь объект, если ключ длиннее предыдущих.

      • KoMaTo3
        /#11359718 / +1

        А потом ещё и коммитить эти, по сути, не изменившиеся строки.

        • k12th
          /#11359730 / +2

          Кстати да.
          По этой же причине я везде пропагандирую обязательную точку с запятой (которая есть в этом гайде) и запятую после последнего элемента массива/объекта (чего в этом гайде нет).

        • VolCh
          /#11360430

          А ревьюверам высматривать что там изменилось в этих строках.

      • mayorovp
        /#11361202

        И еще к тому же нажимать Ctrl+Z если IDE слишком умная :-)

    • smart_alex
      /#11360008

      Горизонтальное выравнивание — чем оно им не угодило? ИМХО, с ним код выглядит куда красивее, как-то структурнее что-ли.


      Полностью согласен. Горизонтальное выравнивание приводит код к псевдо-табличному виду и сразу становится видна структура повторяющихся паттернов кода, а вместе с ней и все технические ошибки (вроде пропущенных скобок, неправильных значений и т. п.).

      Кроме этого, такое форматирование упаковывает многостраничные простыни в компактные «таблицы». Я этим подходом пользуюсь постоянно и не счесть, от скольких ошибок и головновной боли он меня избавил.

      А переформатитирование кода при изменении — это очень небольшая цена за те преимущества, которые даёт этот подход.

  5. TiesP
    /#11359608 / +1

    Какое-то противоречие между соседними правилами: "Используйте шаблонные строки вместо конкатенации" и в следующем — "Google рекомендует применять конкатенацию для длинных строк ". Было бы логично применять для длинных строк такие же шаблонные строки (ограниченные символом `) и переносить эти длинные строки в коде уже произвольным образом.

    • Sirion
      /#11359616 / +2

      Если использовать шаблонные строки с переносом, то происходит либо пичалька с индентацией, либо пичалька с лишними пробелами/табами внутри строк.

      • TiesP
        /#11359646

        А как это проверить? Вот только что в коде все три варианта по очереди попробовал и на узком экране в браузере они абсолютно одинаково отрисовались. Конечно, возникает проблема с авто-форматированием, потому что редактор их не трогает. Как напишешь, так и будут выглядеть.

        • VolCh
          /#11360438

          Внутрь HTML выводили?

          • TiesP
            /#11360894

            Да, в div.

            • VolCh
              /#11361088

              Ну так браузеры при парсинге или рендерниге (не помню точно) HTML "схлопывают" по умолчанию все пробельные символы в один. Выведите в <pre> или просто console.log

              • mayorovp
                /#11361208

                При рендере, конечно же. Если бы это делалось при парсинге — то свойство CSS white-space не могло бы работать.

    • TiesP
      /#11359640

      //sehr gut
      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.`;
      

      • ReklatsMasters
        /#11359726

        Не то, чтоб это реально очень хорошо. У вас все переводы строк и отступы тоже запишутся в строку, тогда как при конкатенации никаких пробельных сущностей в строке не будет. Об этом нужно помнить.

        • TiesP
          /#11360892

          Ясно, разобрался. По умолчанию браузер игнорирует множественные пробелы и переносы строк в HTML. Поэтому разницы в отображении не было. По большому счету разница между этими вариантами будет, если установить свойство white-space: pre-wrap (pre сохранит длинную строку вообще без переносов, поэтому вряд ли бы использовался)

  6. stardust_kid
    /#11359688 / +1

    Насчет es6 модулей информация устарела. Сегодня модули стали частью стандарта и поддерживаются почти всеми браузерами.

    • alexkbs
      /#11361122

      Почти 30% оставшихся — не поддерживают, к сожалению.


      Usage, Global 68.08% + 1.11% = 69.19%

      • stardust_kid
        /#11361474

        Как бы мы ни хотели, в осла и оперу мини поддержку модулей не запилят. К тому же есть webpack/parcel/rollup. Странная рекомендация, в общем. Имеет смысл только внутри Google.

  7. TheDeadOne
    /#11359698 / +1

    Первый абзац публикации звучит так, будто Google JavaScript Style Guide — это что-то новое. Но он существует с 2010-го года.

  8. vlasenkofedor
    /#11359756

    // good
    [1, 2, 3].map((x) => {
      const y = x + 1;
      return x * y;
    });

    Зачем здесь объявлять переменную внутри цикла?
    return x * x  +x

    Какой смысл этого кода? Полученное значение нигде не используется. Да и оптимизатор js не должен его исполнять
    один аргумент в стрелочной функции можно без скобок и в данном примере без слова return
    ведь так и буковок меньше
    let arr = [1, 2, 3].map(x => x * x + x);

    • Sirion
      /#11359764

      Считается, что если все промежуточные результаты вычислений сохранять в отдельные переменные, от этого охренительно провышается читаемость. А от выражения с более чем одним арифметическим действием у программиста может случиться инсульт.

    • xadd
      /#11359774

      Промежуточные переменные нужны для самодокуменирования кода, чтобы потом коллегам не приходилось взламывать ваш однострочник.

      • vlasenkofedor
        /#11359844

        конкретно к данному примеру ваши пояснения не относятся

    • MacIn
      /#11360206

      Почему не x * (x + 1)?

      • vlasenkofedor
        /#11360234

        символов меньше и скобочки 2 пальцами ставим

  9. dom1n1k
    /#11359898

    В примерах кода на StackOverflow и других площадках мне до сих пор попадается var. Не знаю, есть ли у этих людей аргументы в пользу такого выбора

    В консоли let писать очень неудобно, потому что если захочешь чуть подправить код и запустить снова — браузер скажет, что такая переменная уже есть. Приходится жать F5.
    Поэтому именно для примеров на SO, которые конечно же захочется быстро проверить-посмотреть, писать var представляется оправданным.

    • mayorovp
      /#11361216

      Ну и надо не забывать что до сих пор не все браузеры поддерживают var (и никогда не начнут поддерживать все, потому что IE заморозили).

  10. alix_ginger
    /#11359940 / +1

    Скажу честно: мне стрелочные функции нравятся просто потому, что они смотрятся лучше и аккуратнее. Но, как выясняется, они еще и служат довольно важной цели.
    … только я вам о ней не расскажу, потому что у вас доку?ментов нету.

    • bingo347
      /#11360734

      возможно ошибаюсь, но думаю речь идет про получение this и arguments из замыкания

    • POPSuL
      /#11360768

      Рискну предположить что важная цель, это сохранение контекста который был вне лямбды (this то есть).


      upd: страницу не обновляй @ комментарии пиши.

  11. Vladek
    /#11360058

    Про const и let я вообще не знал, но я стараюсь писать на Javascript как можно реже.

  12. Lexicon
    /#11360378

    И вроде есть привычки, которые переношу всюду, где есть власть, но по сути переключить свой стиль под линтер — 0 проблем.


    Имхо ни один из примеров не только почти никак не влияет на работу и даже читаемость, но и легко исправляется в процессе CI

  13. YemSalat
    /#11360738

    Точки с запятой необходимы

    Давно уже перешел на standard и не парюсь

    Заголовок спойлера
    Brendan Eich пишет без точек с запятой :)
    https://brendaneich.com/2012/04/the-infernal-semicolon/

  14. taujavarob
    /#11361952

    Сделайте const вариантом по умолчанию, кроме те случаев, когда переменной нужно присвоить новое значение.

    А есть случаи когда переменной ну никак, никак нельзя, в коде, присвоить новое значение?

    Если у вас есть
    const PI = 3.14;

    То означает ли это что ваша программа (модуль, функция) грохнется, если изменить это значение на

    PI = 3.14159265359;

    Когда вы, как программист, пишите или видите в коде const — что вы должны почувствовать из-за этого?

    • что где-то дальше в коде значение этой переменной нельзя менять вообще?
    • что где-то дальше в коде значение этой переменной менять вообще-то можно, но программист решил этого просто не делать?
    • что значение этой переменной строго задано на веки вечные и программист не гарантирует что при ином значении программа вообще будет правильно выполняться?


    То есть, когда я вижу в коде const — но мне нужно поменять значение этой переменной, то должен ли я впадать в ступор от размышления — чем это чревато и чем руководствовался вообще тот программист кто вставил это const в этот код? — Не пометил ли он просто все переменные, которые в коде его не меняются, этим const — руководствуясь правилом — метим всё const, а затем уже тем переменным, значение которых меняем при разработке(написании кода), изменяем на let? — Но тогда этот программист страховался от чего?

    Напрашивается вывод: const не нужен. (С), достаточно:

    let PI = 3.14;

    И не заморачиваться правилом: «метим всё const, а затем уже тем переменным, значение которых меняем при разработке(написании кода), изменяем на let.»

    P.S. Короче:
    — Вы ставите const чтобы указать что при этом значении вы гарантируете работоспособность вашего кода, при ином нет такой гарантии?

    — Вы ставите const чтобы указать (кому-то иному или самому себе?) что при написании этого кода вы дальше не меняли величины этих переменных, но если кому надо (при рефакторинге) их поменять, то пусть ставит тогда и только тогда let взамен const?

    — Вы ставите const чтобы указать компилятору что-то такое чего он сам знать не может или ему это узнать трудно, но он (компилятор) мог бы типа это знание применить у себя для оптимизации выполнения вашего кода?

    — Вы ставите const потому что Google посоветовал вам ставить const? Он большой, ему видней?

    • dom1n1k
      /#11362288 / +3

      Какой обильный и несуразный поток сознания.