Learning a Bit of JavaScript

This week in DPS909 we talked a bit about JavaScript. This was particularly relevant to my project this semester, implementing a few functions in the Processing.js JavaScript library. As part of this week's journey of the mind, we were directed to watch a lecture by Douglas Crockford called "JavaScript: The Good Parts". Leaping over to Wikipedia for some familiarization, Crockford is the senior JavaScript Architect at Yahoo!, and wrote the specification for JavaScript Object Notation. The lecture in the video is based off his book of the same name.

Right off the bat, I'm one of those people who, as Crockford' puts it, started tinkering with JavaScript without learning it. So given my novice credentials coupled with a pressing need to "learn more" I'm pleased that the lecture had a few "do and don't" pointers that someone like me could take away.

The first big thing I learned was use ===, avoid ==. I was first exposed to === by David Humphrey, who gave me a code snippet demonstrating how to detect if a JavaScript variable was an array. A bit of research revealed === compares not only the value of two variables but their types as well, a very useful feature in a language with dynamic typing. I was, not, however, inclined to use === near exclusively.

After watching Crockford's lecture made me realize using mainly == would eventually cause grief.. Sooner or later I would make compare two values, forget the variable types, or forget the distinction between null and undefined, and end up with an annoying, very small, difficult to track down, bug. Using === would be an easy way to save a bit of heartache in the future, which is always a good thing.

Learning the distinction between null and undefined was an ancillary to the first major thing I picked up. The former is a value for an object variable, the latter can be had if trying to retrieve a variable an object doesn't have. Note to self: further research required.

The second, and most surprising, thing I learned was coding style matters. It's easy to mistake JavaScript for a free-wheeling language: dynamic typing, you don't have to use semi-colons half the time! But apparently something as "simple" as bracket placement when defining blocks can really mess things up. Crockford gave the following example:

return 
{
 ok: false
};

This seems innocent enough, but apparently behind-the-scenes shenanigans means it actually is interpreted like so:

return;
{
 ok: false;
}

In other words, everything after return goes nowhere and does nothing. For this to work as intended the opening bracket must be placed to the right of return like so:

return {
 ok: false
};

While my coding style generally resembles the "correct" example, this will be a useful tidbit when deciphering the code of other programmers.

Fortunately, it seems Crockford has developed JavaScript code quality checker called JSLint to help developers catch some of their more egregious code. Methinks I shall be availing myself of it in the near future.