When to use const rather than let

[wbamberg]

This has come up as part of the project to modernize our use of JS in the Learning Area (mdn/content#10337).

In these docs we have almost totally removed usages of var, but the code examples don't seem to use const or let very consistently. For example, one of the very first code samples:

const para = document.querySelector('p');

para.addEventListener('click', updateName);

function updateName() {
  let name = prompt('Enter a new name');
  para.textContent = 'Player 1: ' + name;
}

Here, para is const, and name is let, but name could just as easily be const. I'm not sure what the rationale is here.

I like the guideline that says "use const when you can and let when you have to", mostly because it's very clear to writers and readers.

This is the guideline we follow (and enforce using ESLint) in interactive-examples.

But if we don't want to follow this guideline, what guideline do we want? Or should I just not touch these in the course of this project?

[hamishwillee]

@wbamberg IMO your guideline should be added to the docs and followed. We can't expect people to use const if most of the docs treat it as a synonym of let. I'm as guilty as anyone of using them in the wrong place - because let always works.

Further, I think we'd like to consider ultimately also running eslint over our examples as well as prettier.

[ddbeck]

I think "do what ESLint prefer-const would require" as a guideline today at least slows the growth of the future cost of actually adopting ESLint.

[hamishwillee]

As an aside, since it looks like we're heading towards this, is there an ESLint configuration we should be using - ideally embedded into mdn/content and magically linked so we all keep the same current settings?

[wbamberg]

The ESLint config for interactive-examples is at https://github.com/mdn/interactive-examples/blob/master/.eslintrc.js , and the config was mostly worked out in collaboration with @ikarasz, in mdn/interactive-examples#250 (comment) and following.

I think "do what ESLint prefer-const would require" as a guideline today at least slows the growth of the future cost of actually adopting ESLint.

prefer-const isn't in the default config for ESLint, so it is an extra choice (but a good one IMO).

One other big prep change for interactive-examples was splitting out the example code into pure JS files, because ESLint wanted that. The lovely thing about Prettier is you don't have to do that, it looks for code blocks embedded in Markdown. IDK if ESLint supports something similar.

[ikarasz]

I think we can use ESlint for embedded code blocks as well with the corresponding plugin.

[wbamberg]

That's good to know!

[dontcallmedom]

I'm supportive of following "use const when you can and let when you have to"

[wbamberg]

I'm closing this, since everyone seems to agree that we should follow the rule "use const when you can and let when you have to" (and eventually enforce it with ESLint).