Code structure JavaScript

1. Teams
2. Comments

In this chapter, we will look at the general structure of the code, the commands and their separation.

Teams

For example, you can do two instead of one alert :

As a rule, a new command takes a separate line - so the code is better read:

In many cases, a semicolon can be omitted if there is a transition to a new line. So it will also work:

In this case, JavaScript interprets the transition to a new line as a command separator and automatically inserts a “virtual” semicolon between them.

However, internal rules for inserting a semicolon are not perfect. In the example above, they worked, but in some situations JavaScript “forgets” to insert a semicolon where it is needed. There are not many such situations, but they are still there, and the errors that appear in this case are quite difficult to correct.

Therefore, it is recommended to put semicolons. Now it is, in fact, the standard.

Comments

Over time, the program becomes large and complex. There is a need to add comments that explain what is happening and why.

Comments can be anywhere in the program and do not affect its performance. The JavaScript interpreter simply ignores them.

Single-line comments begin with a double slash // . The text is considered a comment to the end of the line:

Multi-line comments begin with a slash-asterisk "/*" and end with an asterisk-slash "*/" , like this:

All comment content is ignored. If you put the code inside /* ... */ or after // , it will not be executed.

Nested comments are not supported!

There will be an error in this code:

In multiline comments, everything is very simple - the comment lasts from the opening /* to the close */ . Thus, the code above will be interpreted as:

The comment opens /* and closes */ :

Code (extra characters above cause an error):

Types of comments

There are three types of comments.

1. The first type answers the question “What does this part of the code do?” .

   These comments are especially useful if non-obvious algorithms are used.

2. The second type of comments answers the question “Why did I choose this solution to the problem?” . And it is much more important.

   When creating the code, we make a lot of decisions, choose the best option from several possible ones. Sometimes for the right choice you need to study and see a lot.

   When you stopped at something - do not throw away the work done, indicate, at least briefly, what you saw and why you stopped at this option.

   This is especially important if the selected option is not obvious, but there is another, more obvious, but wrong decision. Indeed, in the future, returning to this code, we may want to rewrite the “difficult” solution to a more “explicit” or “optimal” one, and then a comment will help us to understand what is what.

   For example: “I chose animation here using JavaScript instead of CSS, because IE is behaving in this place incorrectly” .

3. The third type of comments arises when we make calculations or variable assignments in one place of the code, which are not used in a completely different place in the code.

   For example: "These values ​​are formatted exactly so that they can be transferred to the server . "

Do not be afraid to comment. The more code in the project - the more important they are. As for the increase in the size of the code - it is not scary, because There are JavaScript compression tools that will easily remove them when publishing code.

In the following classes we will talk about variables, blocks, and other structural elements of a JavaScript program.