“Humans avoid change unless they see immense and immediate personal benefit.
constisn’t about personal benefit or immediate benefit. It’s about long term benefit to others—those that read your code.”
const has been available in both Chrome (20) & Firefox (13) since summer 2012, it didn’t become part of my core JS vocabulary until Mr. Schlueter announced Node v0.10 in the spring of 2013.
const on MDN when I was still using Node v0.6, but:
- I wasn’t eager to fill my JS with the constraints I had when programming for iOS (types, static, private, et al)
- I was introduced to isomorphic JS early on and didn’t want to use transpilers for client-side code for what amounted to a minor readability aide
- Naming variables in such a way that, if entered into Google Translate, would make sense in another language. I was teaching Japanese developers that weren’t fluent in English, and this is just a good way to train yourself to write meaningful variables for folks that speak English as a first language as well!
- Always, always, always putting requires, constructors, prototype declarations, exports and other common statements in the same place in each module
- Taking (what I would call) full advantage of linters and style tools
- Endeavoring to unite approaches between client and server. This led to several new practices, but Browserify was perhaps the most important of those
- Creating or consuming documented modules for all repeated tasks. From checking if something is an Array, to connecting to a CouchDB instance, let’s keep things DRY, sharable & effortlessly learnable
- Most importantly, an overall guiding principle. That is, always side with code decisions that lead communicate more information over code decisions that decrease typing effort or simply impress others in their syntactic athleticism
Number 6 above is where
const comes in. Quite simply,
var makes code harder to read (harder to predict) than
var by re-using pointers like it’s 1982 and they need to hoard them like Qualudes in Jordan Belfort’s basement. The result is, when you see
foo somewhere, it’s pretty tough to know if it’s what it was when
var foo = 'FOO' or something else it got assigned to somewhere else in your app’s codebase. With
const, that’s not true. While that is a seemingly minor change, the culmination of using
const everywhere that it’s appropriate is that your entire app is more predictable. It is, in part, for this same reason that using immutable data structures makes code more readable.
var exclusively for a long time. Thus, my practice of using
const has met some resitance. And hey, it’s natural. Humans avoid change unless they see immense and immediate personal benefit.
const isn’t about personal benefit or immediate benefit. It’s about long term benefit to others—those that read your code. Anyway, I’ve consistently heard a small set of arguments against using
const. They are:
- What if I want to change the value later? I want my pointers to stay flexible
constdoesn’t freeze the object. That’s confusing!
constis harder to type than
constfail on most browsers?
Each of those arguments / questions are unbelievably easy to address. In order:
- a) We don’t program for “just in case” b) You can create a new pointer or change
- That’s a fundamental misunderstanding of computer science / how memory works. Ignorance of the law is not an excuse ;)
- Really? If you will never have your code read by someone else, then feel free to save yourself 2 chars a line :)
- This is the most valid question. If you’re programming for Node, just use it. It works at least as far back as v0.6. Any remotely recent version of FF or Chrome supports it, but IE didn’t support it until 11. Now if you’re using any ESNext|ES6 features via Babel or related tools, you can certainly use
'use strict' to be off to use
const, in some engines you need
'use strict' to be on! The good news is, your chosen JS engine will loudly let you know when this is the case either way.
In most engines
const initially didn’t throw a
SyntaxError when you attempted to reassign to the pointer! The assignment statement would return the value you attempted to assign as if it worked, but when you accessed the value the
const actually points to, it’d be the original value.
It’s specified that a
const statement must contain an actual assignment, unlike
var statements, which can be empty. In earlier implementations of Firefox’s Spidermonkey (and perhaps other engines?), an error was not raised when a
const declaration didn’t end with a value assignment.
Hopefully this has explained why I have Constant Craving!