Ode to const

Some time ago I stumbled upon this article by Kyle Simpson (aka @getify)

Sure const and let are new pals in JS-town, and we still have to understand properly their role, anyway, it’s been almost a year I’m using ES2015 regularly in my projects, and I really like the new variable declarations. I found them to enforce a much stricter semantics for your code: while var hoisting allows unintuitive behaviours, with const and let you know exactly where and how your variables are available.

Const until proved innocent

Because of this I’ve developed the habit of going “const by default”, that is, declaring every variable as const if I’m reasonably sure it doesn’t need to be mutated, or use let otherwise.

This habit lead to less permissive code that breaks easily if I violate my constraints.

Freeze’em all

Kyle makes a good point noting that const enforces only “assignment immutability”, that is you can’t reassign a const value but you can mutate its properties. Meh.

I agree with him when he says this a confusing behaviour. At least disappointing. Yet he proposes a good solution: deep-freeze those values to reach the ultimate immutability goal (Babel plugin, anyone?).

Finally, the rant

The last part of Kyle’s post presents two approaches to variable declarations: my “const by default” (*crowd cheers*) and another he advocates “var by default” (*crowd boos*). Read the article for additional details (read the article anyway because it’s a thoughtful perspective on the topic).

This is the third step of “var by default” approach.

Refactor let to const only after some code has been written and you’re reasonably sure that you’ve got a case where there shouldn’t be variable reassignment.

I’m of a different opinion.

If you are writing code, you should be aware of what are the constraints you put on your programming tools (e.g. variables).

Declaring variables with const should be a thoughtful action, and not something you correct later because you noticed you don’t actually reassign the variable. You should declare a const thinking “this isn’t going to change value because of the way the code I’m writing is going to work”. 
If you later notice it was actually better to use let/var, because you realized that mutating that value could be convenient when refactoring that piece of code in something less stubborn, then it’s ok.

But

1. Refactored code is not the same code, is a different version of the code which does the same thing in a different way. That means now the variable has a different role, and then it’s mutability can (and should anyway) be reconsidered.
2. If in doubt, const (or const+freeze) is a more conservative choice and thus less error prone.
   If you (or someone else working on the same code) find yourself reassigning it later in the program, the interpreter will raise an error: you are noticed of the conflict between what the code does and what you think it should do or what you suppose it’s doing. But the opposite doesn’t happen, and there’s a chance you later reuse a variable you previously assumed to be immutable, and the only way to notice the conflict is debugging the hell out of your code, because no one is going to say you “dude, that was a constant value!”.

What do you think?

Please destroy my arguments on Twitter.