1. Function declaration and function expression
In ECMAScript, the two most commonly used methods to create functions are function expressions and function declarations. The difference between the two is a bit dizzy, because the ECMA specification only makes it clear: function declarations must have an Identifier (that is what everyone often calls function name), while function expressions can omit this identifier:
Function declaration:function function name (parameter: optional) { function body }
Function expression:function function name (optional) (parameters: optional) { function body }
Therefore, it can be seen that if the function name is not declared, it must be an expression. But if the function name is declared, how do you determine whether it is a function declaration or a function expression? ECMAScript is distinguished by context. If function foo(){} is part of the assignment expression, it is a function expression. If function foo(){} is contained in a function body, or at the top of the program, it is a function declaration.
function foo(){} // declare, because it is part of the programvar bar = function foo(){}; // Expression, because it is part of the assignment expression
new function bar(){}; // Expression, because it is a new expression
(function(){
function bar(){} // Declare it because it is part of the function body})();
There are very subtle differences between expressions and declarations. First, a function declaration will be parsed and evaluated before any expression is parsed and evaluated. Even if your declaration is on the last line of the code, it will be parsed/evaluated before the first expression in the same scope. Refer to the following example, the function fn is declared after alert, but when alert is executed, fn is already defined:
alert(fn());
function fn() {
return 'Hello world!';
}
In addition, there is another point that needs to be reminded that although function declarations can be used in conditional statements, they are not standardized, which means that different environments may have different execution results. Therefore, in this case, it is best to use function expressions: because there is no concept of block-level scope in conditional statements.
// Don't do this!// Because some browsers will return the function of the first, while some browsers will return the second one
if (true) {
function foo() {
return 'first';
}
}
else {
function foo() {
return 'second';
}
}
foo();
// On the contrary, in this case, we need to use function expressionsvar foo;
if (true) {
foo = function() {
return 'first';
};
}
else {
foo = function() {
return 'second';
};
}
foo();
The actual rules for function declaration are as follows:
Function declarations can only appear in the program or function body. Syntactically, they cannot appear in Block ({ … }), for example, in if, while, or for statements. Because Block can only contain Statement statements, but cannot contain source elements such as function declarations. On the other hand, if you look at the rules carefully, you will find that the only situation where you can make an expression appear in a Block is to make it part of the expression statement. However, the specification clearly stipulates that expression statements cannot start with the keyword function. This actually means that function expressions cannot also appear in Statement statements or Blocks (because Blocks are composed of Statement statements).
2. Named function expressions
When it comes to named function expressions, it must have a name. The previous example var bar = function foo(){}; is a valid named function expression, but one thing to remember: this name is only valid within the newly defined function scope, because the specification stipulates that the identifier cannot be valid within the peripheral scope:
var f = function foo(){
return typeof foo; // function --->foo is valid within the internal scope};
// foo is not visible externallytypeof foo; // "undefined"
f(); // "function"
Since this is the requirement, what is the use of naming function expressions? Why name it?
As we said at the beginning: giving it a name can make the debugging process more convenient, because during debugging, if each item in the call stack has its own name to describe it, the debugging process will be too pleasant and the feeling will be different.
tips:A small problem is raised here: in ES3, the scoped object of named function expressions also inherits the properties of . This means that just naming the function expression will also introduce all attributes in the scope. The results may be unexpected.
var constructor = function(){return null;}
var f = function f(){
return construcor();
}
f(); //{in ES3 environment}
The program looks like it will produce null, but it will actually produce a new object. Because named function expressions inherit within their scope (i.e., the constructor of Object). Just like with statements, this scope will be affected by dynamic changes. Fortunately, ES5 fixed this bug.
A reasonable solution to this behavior is to create a local variable with the same name as the function expression and assign a value to null. Even in an environment where function expression declarations are not wrongly promoted, using var to redeclaring variables ensures that variable g is still bound. Setting the variable g to null ensures that duplicate functions can be garbage collected.
var f = function g(){
return 17;
}
var g =null;
3. Named function expressions in the debugger (call stack)
As I said just now, the real use of named function expressions is debugging, so how to use them? If a function has a name, the debugger will display its name on the call stack when debugging. Some debuggers (Firebugs) sometimes name and display your functions, so that they have the same role as those of the convenience of applying the function. However, usually, these debuggers only install simple rules to name them, so they are not very valuable. Let's take a look at an example: no need to name a function expression.
function foo(){
return bar();
}
function bar(){
return baz();
}
function baz(){
debugger;
}
foo();
// Here we use 3 function declarations with names// So when the debugger goes to the debugger statement, the Firebug call stack looks very clear and clear// Because the name is clearly displayedbaz
bar
foo
expr_test.html()
By viewing the information of the call stack, we can clearly know that foo calls bar, and bar calls baz (and foo itself is called within the global scope of the expr_test.html document). However, there is another exciting thing, which is the function of Firebug naming anonymous expressions as mentioned earlier:
function foo(){
return bar();
}
var bar = function(){
return baz();
}
function baz(){
debugger;
}
foo();
// Call stack
baz
bar() //Did you see it?foo
expr_test.html()
Then, when the function expression is a little more complicated, the debugger is not so smart, and we can only see question marks in the call stack:
function foo(){
return bar();
}
var bar = (function(){
if () {
return function(){
return baz();
};
}
else if () {
return function() {
return baz();
};
}
})();
function baz(){
debugger;
}
foo();
// Call stack
baz
(?)() // Here is a question mark, it is displayed as anonymous function (anonymous function)foo
expr_test.html()
In addition, when assigning a function to multiple variables, depressing problems will also occur:
function foo(){
return baz();
}
var bar = function(){
debugger;
};
var baz = bar;
bar = function() {
alert('spoofed');
};
foo();
// Call stack:
bar()
foo
expr_test.html()
At this time, the call stack shows that foo calls bar, but in fact it is not the case. The reason for this problem is that baz and another function containing alert ('spoofed') have a reference swap.
Ultimately, the most delegated method is to use named function expressions. Let's use a name-based expression to override the above example (note that the names of the two functions returned in the expression block called immediately are bar):
function foo(){
return bar();
}
var bar = (function(){
if () {
return function bar(){
return baz();
};
}
else if () {
return function bar() {
return baz();
};
}
})();
function baz(){
debugger;
}
foo();
// I saw the clear call stack information again!baz
bar
foo
expr_test.html()