Scope

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Douglas Crockford: Scope is one of the most important inventions in programming. We got it from ALGOL 60. Almost all modern languages have block scope, JavaScript doesn't. JavaScript only has functions scope, which turns out it's not a bad thing. That function scope is sufficient for writing good programs. The problem is that most programmers who are writing in JavaScript were trained in Java or C or other C-ish languages, and expected to have block scope.

[00:00:34]
And the rules about where you declare variables are different in block scope languages versus function scope languages. And that confusion can cause errors. And this is because of the crazy way that the var statement works. We'll look more at var this afternoon. So because of this craziness, I recommend declare all of your variables at the top of the function because that is where JavaScript actually will declare them.

[00:01:01]
And so if you put your declarations there, that increases the likelihood that who is ever reading your program will correctly understand what the program is doing.
>> Douglas Crockford: I find the place that gets people the most confused is in the induction variable of the for statement. They really want to save our I there.

[00:01:23]
And I recommend no, don't even do it there. Move the bar I to the top of the function. And they get really upset, and they start screaming and they say, but that's not how you write it in Java. And I say, write in the language you're writing in.

[00:01:40]
That Java is a different language. They look similar but it's a different language with a different set of bad parts. In JavaScript, you don't wanna be doing that because it doesn't do what you imagine it does. In EX6, which was published in June of this year by the ECMA General Assembly.

[00:02:02]
There's now a let statement in JavaScript which is now starting to find its way into implementations and when that becomes totally ubiquitous, I will recommend stop using var, use let from now on because let will respect block scope. Unless your code has to run on IE 6 because let is a syntax error on IE 6 and your code won't ever run or in IE 7 or on IE 8 or IE 9 or IE 10 or IE 11, but if you have to run on Edge 2 or whatever the next one is gonna be called.

[00:02:42]
Yeah. Let. Otherwise, keep using var.
>> Speaker 2: [LAUGH] Does the current Edge allow let?
>> Douglas Crockford: I don't know.
>> Speaker 2: Okay.
>> Douglas Crockford: It might. I don't know.
>> Speaker 2: We'll all be good in 2016, because Microsoft's dropping support for all those IE browsers.
>> Douglas Crockford: I know your customers will be using these browsers.

[00:03:06]
Yeah. Microsoft said we're not supporting you guys anymore but that doesn't mean that the world's gonna stop using it. So we're gonna be stuck with IE for a while longer, I'm afraid. So global variables are evil in all languages they caused coupling of things, and accidental collisions and security hazards and all sorts of badness.

[00:03:25]
And unfortunately, in the browser the use of global variables is required because there is no kind of linkage mechanism that allows one compilation unit to find another. They just all share a common global space which is crazy. So because of that I recommend in browser applications use as few global variables as possible and when you do, name them all in uppercase because you want them to really stand out as something that is dangerous and important.

[00:03:56]
JavaScript has a new prefix that was modeled after the C++ and Java new prefix. I don't recommend using it ever but because one of the hazards with it is that if you forget to put the new prefix on the front of a constructor function, instead of creating a new object it will clobber global variables.

[00:04:17]
And happen to have the same names as the instance variables you're trying to initialize which is awful, and there's no run time warning no compile time warning it's just awful. So because of that, we have a convention in JavaScript that constructor functions should be named with InitialCaps and nothing else should ever be named with InitialCaps.

[00:04:40]
This is the only clue we have as to what requires a new prefix and what doesn't.
>> Douglas Crockford: This is something which is allowed in JavaScript but it doesn't mean what people expect. So this approach appears to do with it does, it's gonna create two variables a and b and initialize them both to 0.

[00:05:04]
What it does instead is, it initializes b to 0 and creates a which also become 0, but this one will not be a locally scoped variable, this one will be a global variable. One of the big design errors in JavaScript is, if you do not explicitly declare a variable in a function JavaScript assumes that you intended for it to be a global variable which is something that was done intentionally to make it easier for the beginners because often they didn't know what variables were at all.

[00:05:37]
But it's makes it much harder for you because if you're not really careful, any of your variables could turn into global variables where they could easily get stepped on. So again, recommend which one of these you mean and write that instead. Write in a way that-
>> Speaker 2: Is it the same way you can declare multiple variables on a range var a comma b comma c?

[00:05:59]
>> Douglas Crockford: Yeah
>> Speaker 2: Does b and c all become global valuables if you do that?
>> Douglas Crockford: No, in this kind of form you're okay. The problem is if you assignment to do that.
>> Speaker 2: Okay, okay.
>> Douglas Crockford: So, write in a way that clearly communicates your intent.
>> Douglas Crockford: This is another one of Thompson's, so the the b language was modeled after BCPL, which was a brilliant little language.

[00:06:27]
BCPL was the first curly brace language. And BCPL got its if statement right, that the parens around the condition were optional. And the curly braces around the consequence were required. Thompson reversed that. Thompson made the parents around the condition required and the curly braces around the consequence optional.

[00:06:53]
Because that looked more like Fortran which was more in the style of the day. So as result, this statement appears to do with this one does but actually does with this one does, that it's going to call c unconditionally. Or someone reading the statement could easily think that c is only gonna be called conditionally, that's a bug.

[00:07:20]
And so because of this, I recommend always put the curly braces in every time, on every if, on every else, on every while, on ever for, every time put the curly braces in. It's just two characters and it's done. And what that does is for very low cost, it makes your program much more resilient, that means that someone else is gonna come in and add to your if statement.

[00:07:47]
They're gonna have a much greater likelihood of being able to do that without introducing her into it which is a really good thing and if you are leaving the curly braces out, you are setting your coworkers up for failure. Which is inexcusable and unprofessional. So always put them in, and I hear from people all the time but you have to go so hard, it's just two characters.

[00:08:11]
It's just two lousy characters and they make your program so much better. That as our processes become more agile, our coding must be more resilient. Cuz our programs are never finished, right? They're always going to be constant states of improvement and we need to code that way. Code our programs so that they are more easily improved over time.