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

я рекомендовал бы вам попробовать такой стиль

если что, то я уже больше 10 лет повседневно работаю с javascript/typescript и перепробовал очень многие вещи. Повсеместный const — одна из первых фич, которые я попробовал при появлении babel и навязал её использование не в одном проекте. Так что я то как раз полноценно с обоими вариантами поработал).
Такие вещи действительно нужно именно пробовать и порой достаточно длительное время, приведу хороший пример: первый рабочий день в новой компании, открываю код и, о ужас:

x == 1

Какое равенство нужно использовать в сравнениях, двойное или тройное? Уверен 99% смело ответят, что тройное, а оставшийся процент — неопределившиеся новички. Я тоже был исключительно за тройное. Спрашиваю — "Ребят, что за г в этом файле?", — "А у нас везде двойное равенство", — "Вроде компания серьёзная, а вы тут дикие какие-то. Вам Интернет отключили? Весь мир исключительно тройное использует!". Мне объяснили как нужно использовать двойное равенство не получая с этого стандартных минусов и в чём с этого будет плюс. И вроде понятно всё объяснили, там и объяснять то нечего, но я подумал: "ересь какая-то", говорю: — "Ну пофиг, буду делать как у вас тут принято, мне же не жениться на местном коде, но я остался при своём мнении", — "Окей, попробуй, посмотрим, что ты скажешь через пол года". Больше это не обсуждалось, но менее чем через пол года при рефакторинге личного кода я добровольно заменял тройное равенство на двойное. Тоже дикий совсем стал). До сих пор с удовольствием пользуюсь этой фичей в личных проектах, но ни разу даже не пытался где либо её пропихнуть, просто знаю, за такие мысли сразу камнями закидают, никто даже на секунду не задумается про попробовать, просто категоричное нет от всей команды. А там как раз была целая команда с удовольствием использующая эту фичу и как мне кажется большинство приходило в неё с теми же мыслями, что и я.

Та же ситуация с повсеместным const, все его используют, а тут какой-то вася какую-то ересь порет, и ладно бы объяснили и успокоился, но нет же, не унимается. Уже вон и в карму наплевали, действительно, да что вообще этот вася возомнил о себе!)). Мне вот как-то и в голову не приходило плевать в карму за отличающееся от моего мнение которое человек пытается спокойно обосновывать. Ну да пофиг, мне ж за карму на хабре не платят, хоть в минус загоняйте. Интересно другое: если завтра какой-нибудь фейсбук/гугл начнёт предлагать подобную ересь и использовать её у себя, то ситуация будет кардинально отличаться — нехотя, но начнут пробовать, а там глядишь и через пару лет станет общественным стандартом. Легчайше! Всего несколько лет назад кто бы мог подумать, что писать js, html и css в одном файле будет считаться нормой. Вот я бы такое предложил? Да сожгли бы!). Вот и получается победа общественного мнения и хайпа на собственным мозгом каждого.
Меня же та ситуация с двойным равенством научила спокойней относится ко всяким странным идеям, в каждом новом проекте я стараюсь попробовать что-нибудь новое, пусть и странное, хотя чаще это относится к каким-то архитектурным решениям, а не к такой мелочи, что мы здесь обсуждаем. Просто хотел показать альтернативный вариант, но, к сожалению, у многих это вызывает лишь желание меня заткнуть.

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

Сделал так:

let a = 5;
let b = 10;
let c = 10;

let x = (a = b ? 1 : a == c ? 2 : 3);

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

Во втором случае typescript (или vscode) убрал лишние скобки.

Когда использовать 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 которая расставляется обдумано.