Transcript from the "Scope" Lesson
[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: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:04:40] This is the only clue we have as to what requires a new prefix and what doesn't.
[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?
>> 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.