Check out a free preview of the full JavaScript the Good Parts course:
The "Common JavaScript Statements" 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:

JavaScript is syntactically a C family language and has very familiar identifiers, comments and operators. Many of the statements in JavaScript like if, switch, for and try/throw will mirror those found it other C family languages. Part 2 wrap-up and questions

Get Unlimited Access Now

Transcript from the "Common JavaScript Statements" Lesson

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

[00:00:04]
>> Douglass Crockford: JavaScript is obviously a member of the C family, syntactically. It's major difference from C is in its type system. So let's look at some of the syntax. Identifiers start with a letter or an underbar or a dollar sign followed by zero or more letters, digits, underbars, or dollar signs.

[00:00:27] By convention, all variables, parameters, members, and function names start with lower case. The only exception is constructors, which should start as upper case, and global variables, which should be all caps. Initial _ should be reserved for implementations. Most of the JavaScript engines have weird secret properties that start and end with underbar.

[00:00:50] I've seen a lot of developers make their weird stuff look the same way, which is bad, because it could potentially conflict with what implementations are doing. So stay away from that. $ was originally added to the language for the benefit of machines. So for code generators, for macro processors, things that want to generate their own names so they could be guaranteed that their names wouldn't conflict with your names.

[00:01:15] Unfortunately, it got out and some clever clowns said, I could have a function called $, no one will ever guess what it does. And now virtually every AJAX library has a magical dollar sign function that, still, nobody knows what they do. So I still recommend not doing that, but it's become really popular.

[00:01:39] We have two conventions for writing comments; // and /*. I strongly recommend the // form because the language has regular expression literals in it. And it's really easy to create // and */ inside of a regular expression literal. So to avoid the problem that that can cause, use //.

[00:02:09]
>> Douglass Crockford: Being a C family language, we have the standard set of C operators. Some of them work a little differently than they do in other languages. For example, we talked about + and the problem it has with concatenation. So we can add a couple of numbers together, and get something which is surprisingly different.

[00:02:28] One way around that is by guaranteeing that the values are numbers before you give them to +. And which you can do by converting. So here I'm adding the string 3 to the string 4, but coercing both to be numbers before the addition so I get 7. Now I put this one in parentheses because I had a ++ next to each other.

[00:02:54] And I did that because there's a possibility that the ++'s might be confused with the ++ operator, which would be a whole another world of stupidity. So we can avoid that by putting the parens in.
>> Douglass Crockford: We have a division operator which can divide two integers, except it will not necessarily produce an integer result.

[00:03:16] And because we are using binary floating point, even the real result we get is not necessarily the one that we expected.
>> Douglass Crockford: We have percent sign, which is the remainder operator, not the modulo operator. And the difference is that remainder takes the sign of the first argument, not the second argument.

[00:03:39] Modulo takes the sign from the second argument, which is usually the more useful thing. So you need to watch out for that. Then we have == and !=. And i recommend that you not use them, that you use === instead.
>> Douglass Crockford: And we saw that. We have &&, which is the logical and operator, or the guard operator.

[00:04:08] If the first operand is truthy, then the result is the second operand, otherwise it's the first operand. It's not necessarily going to return true or false. It's going to return one of the two values that was given.
>> Douglass Crockford: But it does do a short circuiting. So by looking at the first one, if it sees a falsy value, it will stop at that point.

[00:04:34] And it can sometimes be used to avoid null pointer exceptions. So here we have an if statement, which is there just to avoid the null reference. We could use the and operator to do the same thing. Since null and undefined are guaranteed to be falsy, trying to call a method on them would fail.

[00:04:58] And so that will succeed only if the first value is truthy and all objects are truthy, so that would work.
>> Douglass Crockford: And we have the logical or operator, which is sometimes the default operator. And it's sort of the opposite of the other one. If the first operand is the truthy, then the result is the first operand, otherwise it's the second operand.

[00:05:20] And we can use it to fill in default values. So here we've got input, which we could be getting from a DOM element. And if it is an empty string, then we'll assign last nr_items instead. One thing to watch out for in doing this is that 0, the number 0, is also falsy.

[00:05:42] So filling in a default for that will probably do something that you don't intend. So this only works for strings.
>> Douglass Crockford: Then bang is the logical not operator, which if the first operand is truthy, then it returns false, otherwise it return true. And so if you do it twice, that produces a boolean.

[00:06:06] It returns truthy into true and falsy into false.
>> Douglass Crockford: We have bitwise operators, which looks a little strange in a language that doesn't have integers. So what it does is it will take the 64-bit double, coerce it into 32-bit int, do the shifting or the masking or whatever, and then convert it back.

[00:06:28] Now in some languages, you'll sometime see someone doing a shift because they think it's faster than a divide or multiply. Don't do that in this language because it's not guaranteed that it actually will be faster. Write instead the thing that's clearer. That's always gonna be the smartest way.

[00:06:47] Then we have a complement of statements, which are for the most part the same as we'll see in C or other languages.
>> Douglass Crockford: Statements can have labels, in particular, for and switch. And while can have them in do. Which allows to break out of deeply nested structures. That's a good thing.

[00:07:11] We have a for statement, which we've already seen. And we have a for in statement, which is a new thing in JavaScript. And because it's uniquely JavaScript, it's broken. So you have to do the filtering of the thing that it returns.
>> Douglass Crockford: We have the switch statement, which is the multiway branch.

[00:07:31] And it's better than C or Javas in that the switch value doesn't have to be a number. In particular, it can be a string, and that turns out to be a really nice thing. And the case values can be expressions, which is also a really nice thing. Particularly if you're writing internationalized applications where you want to test for yes or no but yes or no could be different in every language.

[00:07:55] There's a way to express that in switch statements in JavaScript that you can't do in other languages. But then there's a fall through things, you need to watch out for that.
>> Douglass Crockford: So there's a switch statement. We have a throw statement. In JavaScript you can throw anything. There is an error constructor.

[00:08:16] You can make exception objects with it, but you don't have to. You can throw an object literal, or you could throw a string, you can throw anything you want. Just be sure that whoever's gonna catch it knows how to catch it. So because we're loosely typed, a try will only have one catch clause.

[00:08:35] So it catches everything. So that clause has to be responsible for looking at what it caught and decide what it wants to do with it. It could then ignore it, or it could throw it up, or whatever it has to do.
>> Douglass Crockford: And JavaScript comes with a largest set of built-in things.

[00:08:57] I've never seen anybody use any of these.
>> Douglass Crockford: Okay, so let's take a break. Do we wanna stop for lunch now or do we wanna keep going?
>> Off Camera: Yeah lunch should arrive in the next 10 to 20 minutes
>> Douglass Crockford: Okay, so let's take a running start on the next one and maybe we'll get halfway through before lunch starts.

[00:09:24]
>> Douglass Crockford: While I'm setting up, are there any questions?
>> Student: One question.
>> Douglass Crockford: Yeah?
>> Student: When you add functions to a prototype, are you adding a significant overhead? If you added 100 to numbers, is that gonna bloat everything in some way?
>> Douglass Crockford: That is a really good question. We'll get to it a little later, but I can answer it now, so,

[00:09:52]
>> Douglass Crockford: Adding something to a prototype is extremely efficient because the prototypes link to it, they don't copy from it. So you can have one function which gets incorporated into thousands of objects and you only pay for one function. That's huge.
>> Student: Does it have an implication on the search time to find things then?

[00:10:15]
>> Douglass Crockford: No, it tends to be pretty linear. I mean, in theory, the deeper your prototype chain, the longer it's gonna take to resolve. But prototype chains tend to be much shorter than class hierarchies, so it tends not to be a factor.