Hi Swizec :wave: :)
Then you may want to say that `const` guarantees that the name will remain bound to that object.
The great-GP is correct in that `const` has nothing to do with immutability besides that. It doesn't necessarily conveys an intent of inner immutability. It just states that whatever is in the variable will stay there until it goes out of scope.
Using `const` whenever possible is good advice, off course.
My experience has been that both the change in value/reference behaviour and the lack of total immutability guarantees when using a const qualifier on a reference type can be a source of bugs.
Languages like C and C++ distinguish more explicitly between value and reference semantics, and likewise between constant pointers and [mutable] pointers to constant data. To some extent that removes those sources of bugs, at the expense of having to write more explicit but verbose types like `const SomeType &` instead of `SomeType` all over the place.
if “let” was “letitbe” I bet const would be more popular
seriously though, I wish they could have chosen a 3-letter word for const in keeping with var and let. I know const exists in other languages, but it doesn’t even mean the exact same thing as some other languages anyway.
"set" or "fix" would be quite nice, given what const actually does.
The TC39 was constrained by the list of reserved words though. `let` and `const` were reserved in ES5, and there was nothing that could have conveyed `mut`.
https://mathiasbynens.be/notes/reserved-keywords#ecmascript-...
Use const by default. If I need let, see if I can refactor to using const.
I've found that actually I can go far without using let, improving my code along the way.
I see a pattern from colleagues. They initialise a variable using let and then branch to figure out what should go inside it. That can be replaced by a pure function.
For loops tend to be the next thing. In that case, they can be replaced by higher order functions/methods without detriment to clarity (usually an improvement).
Perhaps the move towards iterators, with async support, will make it more common and legitimate. I haven't yet used those in a codebase but perhaps let in that instance leads to clearer code.
I don't want to detail the discussion, but I would love to see some of your code. I contend with this antipattern often but solve it in different ways often depending on language features. If you're doing anything other than simply calling an auxiliary method with a ton of parameters, I would appreciate seeing your solution in Javascript, a language that I'm learning but not proficient in.