The first thing weâll study is the building blocks of code.
Statements
Statements are syntax constructs and commands that perform actions.
Weâve already seen a statement, alert('Hello, world!'), which shows the message âHello, world!â.
We can have as many statements in our code as we want. Statements can be separated with a semicolon.
For example, here we split âHello Worldâ into two alerts:
alert('Hello'); alert('World');
Usually, statements are written on separate lines to make the code more readable:
alert('Hello');
alert('World');
Semicolons
A semicolon may be omitted in most cases when a line break exists.
This would also work:
alert('Hello')
alert('World')
Here, JavaScript interprets the line break as an âimplicitâ semicolon. This is called an automatic semicolon insertion.
In most cases, a newline implies a semicolon. But âin most casesâ does not mean âalwaysâ!
There are cases when a newline does not mean a semicolon. For example:
alert(3 +
1
+ 2);
The code outputs 6 because JavaScript does not insert semicolons here. It is intuitively obvious that if the line ends with a plus "+", then it is an âincomplete expressionâ, so a semicolon there would be incorrect. And in this case, that works as intended.
But there are situations where JavaScript âfailsâ to assume a semicolon where it is really needed.
Errors which occur in such cases are quite hard to find and fix.
If youâre curious to see a concrete example of such an error, check this code out:
alert("Hello");
[1, 2].forEach(alert);
No need to think about the meaning of the brackets [] and forEach yet. Weâll study them later. For now, just remember the result of running the code: it shows Hello, then 1, then 2.
Now letâs remove the semicolon after the alert:
alert("Hello")
[1, 2].forEach(alert);
The difference compared to the code above is only one character: the semicolon at the end of the first line is gone.
If we run this code, only the first Hello shows (and thereâs an error, you may need to open the console to see it). There are no numbers any more.
Thatâs because JavaScript does not assume a semicolon before square brackets [...]. So, the code in the last example is treated as a single statement.
Hereâs how the engine sees it:
alert("Hello")[1, 2].forEach(alert);
Looks weird, right? Such merging in this case is just wrong. We need to put a semicolon after alert for the code to work correctly.
This can happen in other situations also.
We recommend putting semicolons between statements even if they are separated by newlines. This rule is widely adopted by the community. Letâs note once again â it is possible to leave out semicolons most of the time. But itâs safer â especially for a beginner â to use them.
Comments
As time goes on, programs become more and more complex. It becomes necessary to add comments which describe what the code does and why.
Comments can be put into any place of a script. They donât affect its execution because the engine simply ignores them.
One-line comments start with two forward slash characters //.
The rest of the line is a comment. It may occupy a full line of its own or follow a statement.
Like here:
// This comment occupies a line of its own
alert('Hello');
alert('World'); // This comment follows the statement
Multiline comments start with a forward slash and an asterisk /* and end with an asterisk and a forward slash */.
Like this:
/* An example with two messages.
This is a multiline comment.
*/
alert('Hello');
alert('World');
The content of comments is ignored, so if we put code inside /* ⦠*/, it wonât execute.
Sometimes it can be handy to temporarily disable a part of code:
/* Commenting out the code
alert('Hello');
*/
alert('World');
In most editors, a line of code can be commented out by pressing the Ctrl+/ hotkey for a single-line comment and something like Ctrl+Shift+/ â for multiline comments (select a piece of code and press the hotkey). For Mac, try Cmd instead of Ctrl and Option instead of Shift.
There may not be /*...*/ inside another /*...*/.
Such code will die with an error:
/*
/* nested comment ?!? */
*/
alert( 'World' );
Please, donât hesitate to comment your code.
Comments increase the overall code footprint, but thatâs not a problem at all. There are many tools which minify code before publishing to a production server. They remove comments, so they donât appear in the working scripts. Therefore, comments do not have negative effects on production at all.
Later in the tutorial there will be a chapter Code quality that also explains how to write better comments.
Comments
<code>tag, for several lines â wrap them in<pre>tag, for more than 10 lines â use a sandbox (plnkr, jsbin, codepenâ¦)