Defining Variables

For the most part, you learned about variables within the context of data storage, but they also have an integral part in your application when it comes to functionality.

When considering variable and function naming, it’s best to make them meaningful and speak to their contents or purpose. For example, using a variable name of “myBestFriend” would be much more helpful than something like, “firstVariableName.” Something else to consider when naming variables is that they can’t start with a number. They can contain numbers, such as “dogs3” or “catsStink4Eva,” but they can’t begin with a number, such as “3dogs.”

Grouping Variables

When you’re writing an application, it’s best to try to group all variables at the top of your JavaScript file or function (when possible) so they can all be immediately cached for later reference. Some people find this method a little unnatural because functions are defined throughout the document, and it’s a little easier to maintain when variables are right there with the function they belong to; but grouping variables at the top is one of those small performance boosts you can give to your application. It helps to think of it as one large file containing JavaScript for an application versus thinking of the file as a collection of one-off actions that get executed. When thinking of it as a single unit, it feels a little better (to me) when I’m grouping all variables together at the top.

You can group variables in your document in two ways. Up to this point we have been using a new var declaration for each variable; a lot of people prefer this method, and it’s perfectly fine to use. An alternative method is to use a single var declaration, using commas to separate the individual variables and a semicolon at the very end. Listing 6.1 shows an example of grouping variables with a single var declaration. Note the commas at the end of each line.

Listing 6.1. Grouping Variables with a Single var Declaration

---

var highSchool = "Hill",
    college = "Paul",
    gradSchool = "Vishaal";

---

There’s no difference in the way you access these variables compared to how you access variables declared with individual var declarations. At the variable level, it’s purely a way to group. It isn’t good or bad at this point—it’s only personal preference. You’ll see both methods in looking through JavaScript others have written, so it’s good to know what’s going on.

You see this style of variable declaration a lot more when getting into objects, methods, and grouping functions together. I prefer it because it feels cleaner and a little more consistent, but as you progress you will settle on a preference of your own. Both are certainly valid methods.

Reserved Terms

JavaScript contains a lot of core functionality. We’ve been over quite a bit of it so far. Beyond that core functionality you will be defining a lot of your own custom code. If the names of your custom JavaScript match up with anything built into the language, it can cause collisions and throw errors. It’s the same as if you’re writing a large JavaScript file—you want to make sure all the function and variable names are as unique as possible to prevent problems and confusion while parsing the information. If you have two functions with the same name, it’s difficult to tell the browser which one to use, so it’s just not allowed.

To prevent these issues with native JavaScript, there are some reserved words (keywords) that you can’t use when defining variables, functions, methods, or identifiers within your code. Following is a list of the reserved words:

• break

• case

• catch

• continue

• debugger

• default

• delete

• do

• else

• finally

• for

• function

• if

• implements

• in

• instanceof

• interface

• new

• package

• private

• protected

• public

• return

• static

• switch

• this

• throw

• try

• typeof

• var

• void

• while

• with

Most of these are no-brainers, like function and var, and under normal circumstances you probably would never come across a situation where something like “implements” would be a reasonable name for a variable or function. If you end up using any of these terms in your code, the console will throw an error and let you know that you’re using a reserved word. With that in mind, I think the value in this list is not so much memorizing it, but rather recognizing that these words map to native actions in the language. It will help you write better code and also aid in learning more advanced JavaScript down the road if you choose to research some of those terms that are beyond the scope of this book, such as public, private, and protected.