Hello and welcome back.
Before we move to more complex parts of JavaScript lets talk a bit more about the JavaScript syntax.
Let’s talk about semicolons.
Semicolons separate JavaScript statements.
Add a semicolon at the end of each executable statement.
When separated by semicolons, multiple statements on one line are allowed. Like this.
var a equals 5 and a semicolon.
var b equals 6 and a semicolon.
var c equals a + b and a semicolon.
Now let’s talk about JavaScript White Space.
JavaScript ignores multiple spaces.
You can add white space to your script to make it more readable.
The write less do more does not apply to whitespace. But don’t go overboard.
The main concern is readability of the code.
A good practice is to put spaces around operators ( = + - * / ).
The following lines are equivalent.
var person white space equals white space quotes Jana semicolon.
And the following statement. var person equals quotes Jana semicolon.
But the first one is much more readable.
And be careful, spaces are not allowed in the variable names.
So how about JavaScript Line Length and Line Breaks?
For best readability, programmers often like to avoid code lines longer than 80 characters.
If a JavaScript statement doesn’t fit on one line, the best place to break it, is after an operator. Like this.
Document dot getElementById and in the braces quotes and demo dot innerHTML equals.
And here we put a new line. Double quotes What’s up doc?
And now something very important, the comments. What are they?
It's a lot of fun to program, but it's not always fun to return to a program you wrote 10 months or a year ago.
Looking at an old program sometimes feels like you're reading a foreign language.
And its no fun reading someone else’s code either if its not readable.
One of the most important lessons you can learn about writing code is that it's not just for the computer.
You’re also writing for programmers.
You should strive not just to write programs that work correctly, but programs that make sense when examined.
You can go a long way in that effort by choosing good names for your variables and functions.
We’ll talk about functions later in the course.
So what else can we do?
JavaScript provides a way to leave messages in your code that can help explain what's happening in a program.
When you look at your code later, you can read these messages or comments and quickly understand what's going on in your program.
So comment are bits of text in your program that are inserted purely to explain things to a human.
The interpreter/compiler will always ignore these comments.
You can add comments anywhere in your JavaScript code.
JavaScript interpreter will simply skip them and treat them as if they don’t exist.
In JavaScript, there are two types of comments possible: a single-line comment and a multiline comment.
Consider: This is a single-line comment and it starts with double slashes.
So anything after two slashes will be ignored by the interpreter.
But this is a multiline comment.
It is everything between slash, star and a star, slash. It’ll also be ignored by the interpreter.
The // single-line comment is appropriate if you're going to put a comment right above a single statement,
or even at the end of a line.
Everything on the line after the // is treated as the comment
And that is why its ignored by the interpreter.
There's no restriction to what can appear inside a single-line comment.
Let’s try an example.
var a equals 42 semicolon and now the comment
two slashes and 42 is the meaning of life
The /* .. */ multiline comment is appropriate if you have several lines worth of explanation to make in your comment.
Here's a common usage of multiline comments.
So I’ll delete the single line comment and add a multiline. Here it goes.
The following value is the answer to all questions in the universe.
And it must end with a star and a slash. Like this.
There are lots of opinions on what makes well-commented code.
We can't really define absolute universal rules.
But some observations and guidelines are quite useful:
Code without comments is suboptimal.
Too many comments (one per line, for example) is probably a sign of poorly written code.
Comments should explain why, not what.
They can optionally explain how if that's particularly confusing.
Ok, great. Now let’s start communication with our users.
Follow me to the next video.