Javascript error-prone knowledge points

forget the side effects of VAR (Side effects when forgetting Var)

The small difference between implicit global variables and well-defined global variables is the ability to make variables undefined by using the delete operator.

Global variables created by VAR (created in programs other than functions) cannot be deleted.

Implicit global variables created without VAR (regardless of whether they were created in a function) can be deleted.

This suggests that, technically, implicit global variables are not real global variables, but they are properties of global objects. A property can be deleted by using the delete operator, but the variable is not:

Define three global variables

var global_var = 1;

Global_novar = 2; Negative example

(function () {

Global_fromfunc = 3; Negative example

}());

Attempt to delete

Delete Global_var; False

Delete Global_novar; True

Delete Global_fromfunc; True

Test the deletion

typeof Global_var; "Number"

typeof Global_novar; "Undefined"

typeof Global_fromfunc; "Undefined"

In ES5 strict mode, an undeclared variable, such as two negative cases in the preceding code fragment, throws an error.

Accessing global objects (access to the global object)

In a browser, a global object can be accessed anywhere in the code through the Window property (unless you do something quite special, like declaring a local variable named window). But in other environments, this handy attribute may be called something else (even unavailable in the program). If you need to access the global object without a hard-coded window identifier, you can do the following at any level of the function scope:

var global = (function () {

return this;

}());

This method can obtain a global object at any time because it is called as a function in the function (not through new constructs), and this always points to the global object. In fact this disease does not apply to ECMAScript 5 strict mode, so in strict mode you have to take a different form. For example, if you are developing a JavaScript library, you can wrap your code in an immediate function and then pass a reference from the global scope to this as a parameter to your immediate function.

Pre-parsing: var dispersion problem (hoisting:a problem with scattered VARs)

In JavaScript, you can declare multiple var statements anywhere in a function, and they act as if they were declared at the top of a function, which is called hoisting (mount/sticky parsing/pre-parsing). A logic error can occur when you use a variable and then re-declare it in the function soon. For JavaScript, as long as your variable is in the same scope (the same function), it is treated as a declaration, even if it is used before the Var declaration. Look at the following example:

Counter Example

myname = "global"; Global variables

function func () {

alert (myname); "Undefined"

var myname = "local";

alert (myname); "Local"

}

Func ();

In this example, you might think that the first alert pops up "global" and the second pops up "Loacl". This may be understandable, because at the first alert, MyName did not declare that the function would naturally look at the global variable myname, but it does not actually work that way. The first alert pops up "undefined" because myname is treated as a local variable of the function (although it is later declared), and all variable declarations are suspended to the top of the function. Therefore, in order to avoid this confusion, it is best to pre-declare all the variables you want to use.

The code snippet above may perform the following behavior as follows:

myname = "global"; Global variable

function func () {

var myname; Equivalent to var myname = undefined;

alert (myname); "Undefined"

myname = "local";

alert (myname); "Local"}

Func ();

To be complete, let's mention something slightly more complex at the execution level. Code processing is divided into two phases, the first of which is the variable, function declaration, and the normal format of the parameter creation, which is a phase of parsing and entering the context. The second stage is code execution, function expressions and unqualified identifiers (for declared variables) are created. However, for practical purposes, we have adopted the concept of "hoisting", which is not defined in the ECMAScript standard and is often used to describe behavior.

For-in cycle (for-in Loops)

The for-in loop should be used on a non-array object's traversal, and looping using for-in is also known as an "enumeration."

Technically, you can use the For-in Loop array (because the array in JavaScript is also an object), but this is not recommended. Because if the array object has been enhanced by custom functionality, a logic error can occur. Also, in For-in, the order (sequence) of the list of attributes is not guaranteed. So the best array uses the normal for loop, and the object uses the For-in loop.

There is an important hasownproperty () method that filters out attributes from the prototype chain when traversing object properties.

Position of left Curly brace (Opening brace location)

The developer has a different preference for the position of the opening brace-in the same row or on the next line.

if (true) {

Alert ("It ' s true!");

}

Or

if (true)

{

Alert ("It ' s true!");

}

In this case, there are benevolent see, but there are cases where the brackets will behave differently. This is because the semicolon insertion mechanism (semicolon insertion mechanism)--javascript is not picky, and when you choose not to end a line of code with a semicolon, JavaScript will help you fill it yourself. This behavior can cause trouble, such as when you return an object literal, while the opening parenthesis is on the next line:

Warning: Unexpected return value

function func () {

Return

The following code does not perform

{

Name: "Batman"

}

}

You will be surprised if you want the function to return an object that contains the name attribute. Because of the implicit semicolon, the function returns undefined. The preceding code is equivalent to:

Warning: Unexpected return value

function func () {

return undefined;

The following code does not perform

{

Name: "Batman"

}

}

About semicolons Note: Just like using curly braces, you should always use semicolons, even if they are implicitly created by the JavaScript parser. This not only facilitates more scientific and stricter code, but also helps to resolve areas where doubts exist, as shown in the previous example.

Javascript error-prone knowledge points