JavaScript the Good Parts JavaScript the Good Parts

JavaScript: Good Parts and Bad Parts

Check out a free preview of the full JavaScript the Good Parts course:
The "JavaScript: Good Parts and Bad Parts" Lesson is part of the full, JavaScript the Good Parts course featured in this preview video. Here's what you'd learn in this lesson:

JSLint is a code-quality tool that defines a professional subset of JavaScript. It lets you know when you are using the bad parts of JavaScript. (NOTE: The instructor video goes out from 19:23-19:32) The curly brace debate: On the right or on the left? It’s a simple example why we should prefer programming forms that are error resistant. Switch statements can introduce fall-through hazards. The cascading effect can lead to more places where errors can live.

Get Unlimited Access Now

Transcript from the "JavaScript: Good Parts and Bad Parts" Lesson

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

[00:00:04]
>> Douglas Crockford: I wrote a programme called JSLint, JSLint is a code quality tool for JavaScript, it's written in JavaScript, it reads my programmes and it tells me when I'm doing things which are using the bad parts, and the bad parts are more likely to increase. Which result in errors and bugs and I don't want that, so I'm glad to have JSLint watching after me.

[00:00:30] And it's free and you should all be using it, and I'll be showing you why as we go on. But it comes with a warning, JSLint will hurt your feelings.
>> Speaker 2: [LAUGH]
>> Douglas Crockford: And I know this is true because I get messages from people all the time constantly saying [SOUND] JSLint didn't like my program.

[00:00:49] Can you change it to not? And after a few years of this I started to wonder if, wait a minute, there's no crying in programming, right? [LAUGH] We imagine ourselves as the most rational people on Earth, right? Because we are the ambassadors to the computers. And the computers will not tolerate anything less than perfection.

[00:01:12] And so we imagine that we must have these incredible intellectual skills in order to allow us to do that. So there's no emotion there, right? But we get incredibly emotional about this stuff. We are ruled by system one, by our guts, to a much larger extent than we know.

[00:01:30] And that's why there's the crying. And so, I spend a lot of time wondering, you know, why are they crying? Because this is a code quality tool. You have to intentionally put your code in it. Expecting it to give you advice on how to make your code better.

[00:01:44] And when it gives you that specific advice to go, wow I don't wanna hear it. So what is this? So, you know this, emotional aspect of programming, can waste enormous amounts of time. You know like you can get a couple of programmers arguing about should you put your curly braces on the left or on the right.

[00:02:05] So, and you can go on for hours about it. Making up stupid arguments that make no sense because it turns out, there is not a good reason to do it one way or the other. It's a completely arbitrary thing. It sort of like driving. There's not a good reason for why we should drive on the left or on the right.

[00:02:23] A couple weeks ago I was in Australia. They drive on the left there. Works just fine, there is no evidence that their accidents rate are greater than ours. It doesn't appear to be any easier or harder to be on one side or the other. But there is really a good reason or us all being on the same side.

[00:02:40] [LAUGH] So just pick a side, once you pick a side, we should all do that. So the origin of this is, Ken Thompson. Who designed the b language, he also designed Unix. And UTFAID and some of the best stuff anybody have ever thought of. And b language influenced C and every language seems that.

[00:03:02] So B was based on another language called BCPL which was was one of the first curly brace languages. And when Thomson was designing it, he decided to put the curly braced on the right, because it just made sense to him. Dennis Ritchie, when he designed B or C, did the same thing.

[00:03:21] But there were guys in their lab at Bell Labs, that said no, we want to put them on the left. I'm sure they had a meeting. And, after a while Thompson Ritchie said, We don't care. This is a stupid argument, we're not gonna wasting more time on it.

[00:03:37] Do what you want, leave us alone, we're gonna keep putting them on the right but yeah. Now Thompson said, he could have told the compiler. They're on the right and if they throw in the left, that's a syntax error. He could have done that and if he had, who knows how many man centuries of time

[00:03:55]
>> Speaker 2: [LAUGH]
>> Douglas Crockford: We could have saved? But he didn't. And so, the problem is still there. And, you have to choose a side because you can't do it both ways on the same program cuz that just looks stupid. We're trying hard not to intentionally look stupid, right? Whole thing is about making stuff that looks smart.

[00:04:18] So if you have somebody who's used to putting them on the left and he goes to work for a shop where they put them on the right, they say, okay, from now on you can put them on the right. And he's gonna start to cry. And he goes, no, I don't wanna put them on the right.

[00:04:33] Then he'll start coming up with all these reasons for why it's important. And he's crying and he's emotional, so that there must be truth here. You wouldn't get this upset if there weren't deep truth. And there is no truth because there's not a good reason, so he's got system 2 trying to synthesize why is system 1 so emotionally connected to these curly braces and it doesn't make any sense, except in JavaScript.

[00:04:58] It turns out in JavaScript you should always put them on the right and never put them on the left. Left, and this is why. We have a return statement that's returning the result of an object literal. This is one of the good parts of JavaScript, being able to create new objects out of nothing is fantastic.

[00:05:20] And if you put the curly brace on the right, this will do exactly right thing, you know, just does what it should. If you put him on the left, it does the worst possible thing. That one will return undefined, it will not return an object. And that crap that´s after it, which should generate some sort of syntax error or warning, does not.

[00:05:47] So, it's a silent error. No compile time warning, no run time warning, it just does the wrong thing. And you may not recognize that it went bad at this point, right, there might be sometime in the future down stream from this when the era actually occurs, when you try to go to an object and it's not there, you know that's gonna be bad, so you happen to be around to debug this, you gonna be looking in that goal where did my object go?

[00:06:13] That's gonna be perplexing, and eventually you might track it back to the statement and you can stare at that for a couple hours, I don't see anything wrong with that. But there is, because one of the bad parts of Java script is automatic semicolon insertion. Which was a well intended but incompetently specked feature, which was supposed to make the language easier for beginners by allowing it to leave the semicolons out and it would put them in for you, and one of the ways it would do that it would be, it would look for a syntax error and if it sees one, it would turn a nearby lying feed into a semicolon and then try again.

[00:06:53] That would freak you out right? But that's [LAUGH] no, so that's a consequent it sometimes doesn't put semicolons where it should and in this case it would put semicolons where it shouldn't. So we put a semicolon right there. Which causes that statement to be the ordinary return and ordinary return returns undefined.

[00:07:15] That's bad. Now if you put your curly brace on the right, you will never experience that, it will always just work. And if you put your curly brace on the left. This hell is waiting for you. Once I had someone come up to me afterward and say, wow, I didn't know that about the semicolon insertion, so from now on, whenever I write a return statement, I'm gonna put it on the right, but all the rest of the time, I'm gonna put it on the left.

[00:07:43] No that's not how you should be thinking about this. That you want to prefer forms that are error resistant. Cuz we are trying to get our error rate down to zero. We are striving for perfection. And, so you look it as a trade off. What's the relative cost of putting the curly brace on the left or the right?

[00:08:06] No cost. Right? No cost. So, if you put it on the right, no cost benefit. This is an error you will never have to fix. That's a good trade off. For free, I can avoid a whole class of errors. That's good. Anytime I can avoid making errors, that's gonna make it a little bit easier for me to start becoming a little bit more perfect and that's what we are going for.

[00:08:30] So, another thing that Thompson invented was the switch statement. And unfortunately it was modeled after the Fortran computer go to statement. We've since learned that go to is considered harmful. And it is. But it still exists in this weird form in the switch statement. And that is that you can have one case which will fall through to the next case unless you explicitly disrupt it by breaking or returning or throwing.

[00:09:01] So one day, someone wrote to me and said, you should have warn about this fall through thing, cuz that's a subtle error and it could be hard to find. And I thought deeply about it. And I wrote back to them and I said, well, I can see that could happen, but there's this elegance that can happen if you can get all of the cases to cascade into each other, and it really is beautiful.

[00:09:30] And you know the error can happen, I can see that, but it hardly ever happens, and you trade that off against the elegance here. So I think I'm not gonna warn on that, I really like that you fall through, I think Thompson got it right.
>> Douglas Crockford: Next day, the same guy wrote to me and said I found a bug in JSLint.

[00:09:52] I said, good, okay, so I throw it in the debugger, you know where this is going, right? Turned out, I had to switch a case that was falling through. And in that moment, I achieved enlightenment.
>> Speaker 2: [LAUGH]
>> Douglas Crockford: Cuz we imagined that we spend all our days power typing, right.

[00:10:12] I'm typing my program, and that's not what we do. That's not what most of the time goes. We spend most of our time making mistakes and correcting them. And going down into the abyss And into that cold, dark place and finding what went wrong and coming back and doing that.

[00:10:33] And then we forget about it, so at the end of day, well, what did you do today? I was power typing, and we think that's what we're doing. And we're not, we're making mistakes. And because, we have this feeling of euphoria that once we find something, poof I found it, it feels so good.

[00:10:53] We black out that other stuff. We completely forget about how much time we spent in the debugger. And as a result, we tend to not learn from our mistakes, you know so you know how many times have you gone through and spend an hour debugging and go [SOUND] that again.

[00:11:11] We do that all the time, but on this occasion there is no way I could avoid running from that mistake because it was so humiliating after I'd just given the speech about why this was a good feature. And then boom, got nailed by it. I had to learn from it.

[00:11:30] Generally, apparently I tried not to but on this time, I couldn't avoid it. There it was, it actually was making my program bug. So the thing I realized from that was, If I never intentionally fall through, I can find the cases where I accidentally fall through. And so it becomes easier to analyze my programs and discover where the defects are.

[00:12:02] And the benefit I saw from the cascading, that was an illusion, that was wrong. It turns out that actually has a negative benefit because you're artificially constructing a code in such a way as to cause that cascading to happen. Which can add cruft to your code which can make it more difficult to maintain and could possibly even introduce bugs in the process of trying to force.

[00:12:28] A code into that kinda pattern. That turned out to have a negative value. I imagine it had a positive value.