Great ideas about JavaScript practice

When you find a good resource like Clean Code JavaScript, please join me in spreading the word. (You can do it here, if you want, but do it somewhere!)

JavaScript programmers: I recommend you consider every idea here and implement those best for you and your projects. There’s a difference between a cook and someone using a cookbook. Your evaluation of a list like this makes you more valuable. Effective implementation of applicable ideas makes your code more valuable.

const: JavaScript ES6 best practice

Summary

The audience for this article is JavaScript programmers. Intermediate programmers are likely to have seen the ES5 information before. The ES6 (ES2015) information might be new to them.

In the JavaScript ES6 world, a growing number of programmers are converting from declaring variables with ES5 “var” to ES6 “const” and “let”. Perhaps unexpectedly, some of them are advocating using “const” for every variable they plan to leave constant during its life. (Those radicals! Only …) I’m joining them.

Note

Some readers may consider this post a large departure from my prior posts. This is not an example of project management content. I expect some future posts to be about PM and some to be about programming. This one is about JavaScript programming. I’ll use tags to separate them.

Detail

definition: In computer code, a problem is a condition that is troublesome enough to change. A near-synonym: bug.

This ES5 JavaScript includes a number of improvable conditions.

var startUSCivilWar = 1861
function example () {

… // More code here.
startUSCivilWar = 1961

// Changing history?

console.log(“The ” + warName +
” started in ” + startUSCivilWar +
“.”)

// Uses the warName declared
// later because of hoisting.

… // More code.
var warName = “U.S. Civil War”

}

Condition 1: Our code declared a variable (startUSCivilWar) outside all functions, so it’s a global variable in the computer environment. Everyone sharing the environment has access to it. Had we happened to use a variable name JavaScript already used, the JavaScript variable is unavailable to us and everyone else using the environment. Suppose we chose a variable name like “Object” or “Array”? (Please don’t do either of those in a production environment! 🙂 ) Ick.

Condition 2: Our code changed startUSCivilWar, which is probably bad; it might not be intentional. It’d be great if the interpreter could help us find the condition.

Condition 3: Our code used a variable warName not declared at time of use. Would you agree that it’s at least ambiguous (maybe even questionable) whether the programmer intended this value for this log statement? Lots of programmers with code like this later consider the code to have a bug (or a problem). Can the interpreter help?

Here comes ES6 with some new options.

const declares a variable whose value the interpreter won’t change.

Both const and let declare a variable that cannot be used before its declaration. The variable is still hoisted; the area where it can’t be used is its “temporal dead zone”. (Fancy term, huh?! Sounds terrible.) See discussion in [Zakas 2016] or elsewhere.

const and let variables declared outside all functions are available globally, but aren’t global variables. The earlier “Object” and “Array” examples would thus block use of those JavaScript variables in your code, but not in others’ code. I say: That’s better.

The same ES6 code might look like (underlines indicate changes):

const startUSCivilWar = 1861
function example () {

… // More code here.
startUSCivilWar = 1961

// Error. Changing a constant.

console.log(“The ” + warName +
” started in ” + startUSCivilWar +
“.”)

// Error. Undeclared
// variable: warName. The
// later one isn’t usable
// until declared.

… // More code.
var warName = “U.S. Civil War”

}

Variable startUSCivilWar is available everywhere in your program, but it is not a global variable.

The interpreter threw a couple errors, each of which give you a chance to change a condition before they’re problems. Further, it flags them during development, before your boss or client sees them in execution. Low cost; high benefit. That’s an easy decision.

Personal experience with const and let: I find that I know at declaration time whether I intend to change the variable value. Using const or let accordingly is an easy habit for me.

Roughly half of my variables are constants. I presume that’ll change with the types of programs I write.

Due credit: I didn’t come up with this. I got it from [Zakas 2016], page 12. I presume lots of other places on the web recommend it. I join them.

Source Mentioned

[Zakas 2016] Nicholas C. Zakas. UNDERSTANDING ECMASCIPT 6. No Starch Press. San Francisco, 2016. ISBN 978-1-59327-757-4. Also here on the web, accessed Wed Oct 19, 2016.