Transcript from the "Avoiding Confusing Code (A)" Lesson
>> Douglas Crockford: Confusion is where bugs come from. When we think a program does one thing, and it actually does something else, that's what confusion is. That's what creates bugs, right? So we want to eliminate as much confusion as possible, we want to be as clear as possible. We want our programs to be something that you can easily reason about.
[00:00:56] Fortunately, we have a triple equal operator, which always does the right thing except for nan and we'll talk about that later. But for all of these it'll produce false, which is the correct answer. So my advice is always use triple equal, never use double equal. And if you do that, then there's a whole lot of confusion which disappears and your programs become more reliable.
[00:01:23] Now what about the case where double equal actually, accidentally sort of does the right thing? Should you use it then? And my advice is no, because you wanna make it clear to the reader that you know what you're doing and you're doing the right thing. And so if they see a double equal in your program, they're gonna have to stop and ask, okay, is this a common error, or does this guy actually know what he´s doing?
[00:01:48] It's harder to make the second argument if you're using this operator, so don't do it. So if there's a feature of the language that is sometimes problematic aand if it can be replaced by another feature that is more reliable, then always use the more reliable feature. That will tend to help us keep the error rate down.
[00:02:29] Nesting is very important to revealing the structure of the program and helping us to interpret what is going on. And this breaks indentation, cuz everything has to go back out to the margin. So it does make programs harder to read, harder to understand. And that's a bad thing.
[00:02:45] But even worse, there is a syntactic danger that this statement is correct, and this one is a syntax error. Can anybody spot the syntax error?
>> Speaker 2: Space on the right slash.
>> Douglas Crockford: Yeah, exactly. There's a space right here. It's obvious once it's pointed out, right? But yeah, that causes syntax error.
[00:03:09] So I don't want to use this, because I want my programs to be obviously correct. And if I'm using forms that you cannot distinguish from common errors, then my programs are harder to understand, and I don't want that. So avoid forms that are difficult to distinguish from common errors.
[00:03:54] The only thing they know for sure is that the programmer was incompetent. That they don't really know what this was supposed to do. So my advice is figure out which of these you intended and write that instead. And don't write the form which is ambiguous. Because anytime you have something that looks like one thing that does something else, that's where errors come from.
[00:04:15] Not every time, but often enough that it's a pattern you want to avoid. So make your programs look like what they do.
>> Douglas Crockford: Scope is one of the best inventions in programming languages. It came into the world in ALGOL 60, which was, by far, the best design by committee in the history of programming languages.
[00:04:37] ALGOL 60 was an amazing leap forward. And one of the leaps was block scope, where you could create variables in a block, and they would not be visible outside of the block. And you could nest blocks, and the inner most block would have access to the variables of the outer block, and that was brilliant.
[00:05:40] So the reason for this the way the VAR statement works. The VAR statement gets split into two parts, the definition part and the initialization part. If you don't have an initialization part, it synthesizes one using undefined. And it moves the declaration part to the top of the function, what they call hoisting.
[00:06:06] So you might think that you're declaring a variable inside of a block, but it actually gets moved to the top of the function. And this can cause errors. It doesn't always cause errors, but it does cause errors. So you shouldn't rely on that. So in a block scoped language, the best advice is declare the variable in the innermost block where it makes sense to, probably at the site of first use.
[00:06:37] That's good advice in a block scoped language, it's bad advice in a function scoped language. In a function scoped language, you want to declare all of your variables at the top of the functions, because that's where they're actually being declared. So you wanna make it easier for someone to understand what the program is doing by having it match what's actually being done.
[00:07:38] And that's wrong, no, it's actually right. Because there are a lot of errors that can occur if you're not aware of that hoisting. And so you really should, you can avoid all of that if you just move them to the top. And you'll say, but this is how you write it in Java!
[00:08:33] And the let statement will be just like the VAR statement, except it will not hoist, which means it will respect block scope.
>> Douglas Crockford: Now at that time on that happy day, my advice will change. And I will say, always use the let statement and never use the VAR statement, unless you have to run on IE6.
>> Douglas Crockford: Or IE7, or IE8, or IE9, or IE10. And we don't know what's in IE11 yet, but pretty sure if you only have to run on IE12 and above, then you'll want to use let statement. Otherwise, you're gonna have to keep using the VAR statement.