Still, I liked some of the example code in this post because it can be used to explain some interesting things about JavaScript as a language. The following is an in-depth explanation of what is happening in each of those examples.
Example #1
This strange looking piece of code seems to say, “if window doesn’t have a property ‘a’, define a variable ‘a’ and assign it the value of 1.” You would then expect the alert to display the number 1. In reality, the alert displays “undefined”. To understand why this happens, you need to know three things about JavaScript.
First, all global variables are properties of
window
. Writing var a = 1
is functionally equivalent to writing window.a = 1
. You can check to see if a global variable is declared, therefore, by using the following:
Second, all variable declarations are hoisted to the top of the containing scope. Consider this simpler example:
The alert in this case outputs “true” even though the variable declaration comes after the test. This is because the JavaScript engine first scans for variable declarations and moves them to the top. The engine ends up executing the code like this:
Reading this code, it makes far more sense as to why the alert would display “true”.
The third thing you need to understand to make sense of this example is that while variabledeclarations are hoisted, variable initializations are not. This line is both a declaration and an initialization:
You can separate out the declaration and the initialization like this:
When the JavaScript engines comes across a combination of declaration and initialization, it does this split automatically so that the declaration can be hoisted. Why isn’t the initialization hoisted? Because that could affect the value of the variable during code execution and lead to unexpected results.
So, knowing these three aspects of JavaScript, re-examine the original code. The code actually gets executed as if it were the following:
Looking at this code should make the solution obvious. The variable
a
is declared first, and then the if
statement says, “if a
isn’t declared, then initialize a
to have a value of 1.” Of course, this condition can never be true and so the variable a remains with its default value,undefined
.Example #2
This code looks far more complex than it actually is. The result is that the alert displays the number 1, the value to which a was initialized. But why is that? Once again, this example relies on knowledge of three key aspects of JavaScript.
The first concept is that of variable declaration hoisting, which example #1 also relied upon. The second concept is that of function declaration hoisting. All function declarations are hoisted to the top of the containing scope along with variable declarations. Just to be clear, a function declaration looks like this:
This is opposed to a function expression, which is a variable assignment:
To be clear, function expressions are not hoisted. This should make sense to you now, as just with variable initialization, moving the assignment of a value from one spot in code to another can alter the execution significantly.
The third concept that you must know to both understand and get confused by this example is that function declarations override variable declarations but not variable initializations. To understand this, consider the following
The variable
value
ends up as a function even though the variable declaration appears after the function declaration. The function declaration is given priority in this situation. However, throw in variable initialization and you get a different result:
Now the variable
value
is set to 1. The variable initialization overrides the function declaration.
Back to the example code, the function is actually a function expression despite the name. Named function expressions are not considered function declarations and therefore don’t get overridden by variable declarations. However, you’ll note that the variable containing the function expression is
b
while the function expression’s name is a
. Browsers handle that a differently. Internet Explorer treats it as a function declaration, so it gets overridden by the variable initialization, meaning that the call to a(--x)
causes an error. All other browsers allow the call to a(--x)
inside of the function while a is still a number outside of the function. Basically, calling b(2)
in Internet Explorer throws a JavaScript error but returns undefined
in others.
All of that being said, a more correct and easier to understand version of the code would be:
Looking at this code, it should be clear that
a
will always be 1.Example #3
If you were able to understand the previous example, then this one should be pretty simple. The only thing you need to understand is that function declarations trump variable declarations unless there’s an initialization. There’s no initialization here, so the alert displays the source code of the function.
Example #4
This code is a bit easier to understand as the only real question you must answer is whether the alert displays 3 or 10. The answer is 10 in all browsers. There’s only one concept you need to know to figure out this code. ECMA-262, 3rd Edition, section 10.1.8 says about an
arguments
object:For each non-negative integer,arg
, less than the value of thelength
property, a property is created with nameToString(arg)
and property attributes{ DontEnum }
. The initial value of this property is the value of the corresponding actual parameter supplied by the caller. The first actual parameter value corresponds toarg
= 0, the second toarg
= 1, and so on. In the case whenarg
is less than the number of formal parameters for theFunction
object, this property shares its value with the corresponding property of the activation object. This means that changing this property changes the corresponding property of the activation object and vice versa.
In short, each entry in the
arguments
object is a duplicate of each named argument. Note that the values are shared, but not the memory space. The two memory spaces are kept synchronized by the JavaScript engine, which means that both arguments[2]
and a
contain the same value at all times. That value ends up being 10.Example #5
I actually considered this to be the easiest of the five examples in this quiz. It relies on understanding two JavaScript concepts.
First, you must understand how the value of the
this
object is determined. When a method is called on an object, this
points to the object on which the method resides. Example:
In this code,
this
ends up pointing to object
when object.method()
is called. In the global scope, this
is equivalent to window
(in browsers, in non-browser environments it’s the global
object equivalent), so this
is also equal to window
inside of a function that isn’t an object property. Example:
Here,
this
ends up pointing to the global object, window
.
Armed with this knowledge, you can now tackle the second important concept: what
call()
does. The call()
method executes a function as if it were a method of another object. The first argument becomes this
inside the method, and each subsequent argument is passed as an argument to the function. Consider the following:
Here, the
method()
function is called such that this
will be document
. Therefore, the alert displays “false”.
An interesting part of ECMA-262, 3rd edition describes what should happen when
null
is passed in as the first argument to call()
:IfthisArg
isnull
orundefined
, the called function is passed the global object as the this value. Otherwise, the called function is passedToObject(thisArg)
as the this value.
So whenever
null
is passed to call()
(or its sibling, apply()
), it defaults to the global object, which is window
. Given that, the example code can be rewritten in a more understandable way as:
This code makes it obvious that the alert will be displaying the string equivalent of the
window
object.Conclusion
Dmitry put together an interesting quiz from which you can actually learn some of the strange quirks of JavaScript. I hope that this writeup has helped everyone understand the details necessary to figure out what each piece of code is doing, and more importantly, why it’s doing so. Again, I caution against using these sort of quizzes for job interviews as I don’t think they serve any practical use in that realm (if you’d like to know my take on interviewing front-end engineers, see my previous post).
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
ref :http://www.nczonline.net/blog/2010/01/26/answering-baranovskiys-javascript-quiz/