Learning JavaScript: Variables, Functions, and Loops
- Defining Variables
- Functions
- Scope
- Loops
- Conditionals
- Putting It All Together
- Summary
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
This is one of the more important chapters in the book because you learn some of the core features in JavaScript. We expand on the variables that were mentioned in the previous chapter, then move on to creating functions, and last, we go over how to loop through data to autoexecute the same code block over and over. Using variables, functions, and loops are often the only thing a person knows how to do in JavaScript, and they usually get along just fine. You’re already past that part and on your way to becoming an elite JavaScript developer, so no worries there. You’ll be coding while all the others are looking up how to do something.
Now that you have a solid base in how to work with a lot of the common things in JavaScript, you can start building an application and producing something tangible. Up to this point in the book, the examples have been pretty specific, but also a little abstract. You’ve been manipulating content and data, then alerting or observing the result. In this chapter we expand on what you’ve learned already and begin building a simple JavaScript application that will get more robust as you step through the subsequent chapters.
As you progress though this chapter, you notice that an address book application should be starting to form. Some of the methods that we go over repeat in their core functionality but have very different use-cases. Although they may not necessarily all live in the same application, this is the chapter where you start building that tangible knowledge that can be directly transferred into a project.
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.