Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Разве это не какое-то известное правило? Раньше, когда использовал javascript, у меня eslint подсвечивал такое заставляя добавлять скобки, причём я специально не настраивал это, то есть у многих должно работать как-то так же. Сейчас typescript как выяснилось не ругается, но при форматировании сам добавляет скобки. В данном случае добавил так:

let a = 5;
let b = 10;

console.log((a = b ? 1 : 2));

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Если вы не планируете её менять, зачем писать код с учетом этого?

потому что я не планирую запрещать её дальнейшее использование, оно ничего не ломает. Мне кажется я повторил это уже раз 20. Вы точно попытались осмыслить?

В 90% (оценочное суждение из головы) случаев никто ваш код трогать не будет никогда. В 9.5% случаев его удалят целиком не читая

у меня другой опыт: пишется один раз, дорабатывается 10 раз, читается 100 раз. Вы реально постоянно всё с нуля переписываете?

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Зачем?

для дальнейшей доработки кода.

На дальнейшее я могу ответить только в том же духе, но не хочу.

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

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

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

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

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Если изменить любую в одном методе, то соседний может сломаться, с этой точки зрения вполне себе)

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Ага:

const PATH = require('path');
const FS = require('fs');
const GULP = require('gulp');
const GULP_DATA = require('gulp-data');
const NUNJUCKS_RENDER = require('gulp-nunjucks-render');
const { t as T } = require('@riim/gettext');

Как-то так себе получается.

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

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

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Ну как бы и я про тоже, что замыканий с не константами в ООП получается совсем мало. Или я неправильно вас понял?

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

больше восьми, ну максимум десяти

маленькое у вас ограничение. Я обычно ограничиваю себя высотой небольшого (macbook) экрана, в этом случае уже не важно значимые строки или нет.

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

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

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

А замыкания в JS используются часто.

а так ли уж часто? Просмотрел сейчас несколько десятков файлов в текущем проекте, да, колбеки есть, но это всегда чистые функции ничего не использующие и не меняющие вне себя. Можно представить ситуацию вроде такой (абстрактный код):

class SomeView extends View {
  onBtnClick() {
    let btn = $('btn');
    btn.disable();
    request.get(...).then(res => {
      btn.enable();
      // ...
    });
  }
}

вроде замыкание, но такого в коде по-хорошему вообще не должно быть. Вот как мне теперь переопределить только обработку ответа при наследовании? Соответственно переписываем так:

class SomeView extends View {
  initialize() {
    this.btn = $('btn');
  }
  onBtnClick() {
    this.btn.disable();
    request.get(...).then(this.onResponse);
  }
  @autobind
  onResponse(res) {
    this.btn.enable();
    // ...
  }
}

Опа-на и нет замыкания)). Причём избавлялись от него не ради избавления от замыкания, а по совершенно другой причине и такая причина в ООП всегда находится.
Плюс есть async/await, то есть даже если точно не нужно выносить обработку в отдельный метод, то так:

class SomeView extends View {
  async onBtnClick() {
    let btn = $('btn');
    btn.disable();
    let res = await request.get(...);
    btn.enable();
    // ...
  }
}

В результате в примерно 35 просмотренных крупных файлов въюшек и стора я не увидел ни одного замыкания с не константой. В файлах сборки тоже не нашёл такого, в основном колбеки в виде чистых функций. Максимум встречаются замыкания с константами:

const gulp = require('gulp');

gulp.task('some-task', () => {
  return gulp. // ...

но это опять же к нашей ситуации не относится.
В результате

Если ссылка никогда не меняется — её безопасно использовать в любых замыканиях.

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

Моё мнение — const по умолчанию хорош только при чисто функциональном стиле программирования. В остальных случаях лучше воспользоваться правилами из той же статьи:

В любом случае это пока единственный хоть сколько-то весомый аргумент за повсеместный const из тех что пока прозвучали.

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

из легаси

ну в легаси всё что угодно может твориться, здесь сложно что-то оценивать.

не затрёте ссылку, которую коллега решил сделать неизменяемой

как не затру, вот я нахожусь в каком-то месте кода, вижу $element, вижу, что это константа, если const расставлялся осмысленно, то да, не затру, ведь мне явно сказано не трогать, а так я лишь знаю, что пока ещё не менялась и всё, скорей всего можно менять просто заменив const на let. Ладно, я проверю точно ли можно так делать, но вот что там делает коллега с его хотфиксом я не знаю. А дальше получаем:

из легаси

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

У меня линтер заставляет обёртывать такое в дополнительные скобки:

if ((a = b)) {

это и при чтении кода помогает, сразу видно, что там что-то не совсем обычно. Можно настроить чтобы совсем не пропускал такое.

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Верно, и всё же пользы от этого на мой взгляд явно меньше.

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Он значит неизменность ссылки. Это может быть полезно и, как минимум, не хуже let.

такая себе польза от знания того, что ссылка нигде не меняется, теряя при этом возможность знать от своего коллеги, что её нельзя менять по каким-то причинам. Ну не меняется она и что? Я для себя не нашёл пользы. Можете привести пример, в какой ситуации вам это что-то даёт?

Вам придется оценивать ее «обдуманность», что сводит на нет пользу этих предположений.

помечено константой — не трогай, создай новую привязку, польза остаётся. Если же нужно как-то поработать именно с этой константой, то да, нужно будет оценить остался ли запрет на изменение.

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Есть там альтернативный смысл или нет, но кода может быть просто много:

const $element = $(...);

// много кода

$element.on("foo", e => {
    $element.bar();
});

// много кода

// а здесь вам стала интересна константа $element

имя для новой переменной придумывать не хочется, может эта сгодится? Как вы это поймёте? Ведь const при его повсеместном использовании не значит ровно ничего.

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

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Так там как раз пример правильного использования const. Там константа и кто-то правильно запретил её менять. Вы привели пример к этому тексту:

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

Я его не писал и процитировал не как какой-то аргумент, а как часть правил при которых большинство констант обычно сами отмечаются правильно. Зря процитировал, сам не согласен с этим предложением, ну а вы нашли к чему придраться.

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

const на let можно менять только после анализа всех мест использования.

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

не следует считать что все вокруг так же делают.

как вы делаете такие выводы? Вы блондинка? Окей, разжую, я имел ввиду, что при обдуманном изменении let-переменной действительно ничего не сломается.

Вы так пишете, как будто всегда можно поменять let-переменную и ничего нигде от этого не поломается...

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

Когда использовать var, let и const в Javascript [перевод статьи Tyler’а McGinnis]

Как мило, адепты повсеместного const минусят также бездумно как и ставят const)). Уверен, большинство даже не пыталось осмыслить написанное.