I am reading Douglas Crockford\'s book \"Javascript: The Good Parts\". He is talking about scope and saying that JS doesn\'t have block scope:
In many mod
That's not always a good idea. It depends what you're doing. What they mean when they say it's not necessary to declare "top level"
variables, is that it doesn't matter. It can matter inside a function. Consider the following examples:
varOne = 1; varTwo = 2; varThree = 3; // undeclared
function lameFunc(){
var varOne = 'Something'; // does no affect varOne at the top level
return varOne;
}
Same as:
var varOne = 1, varTwo = 2, varThree = 3; // declared
function lameFunc(){
var varOne = 'Something'; // does no affect varOne at the top level
return varOne;
}
Of course, it's easier to see the variables with the keyword var
and since there are no adverse effects at the "top level"
, it is recommended.
Notice that, when I change lameFunc()
you affect the higher lever var
, either way.
function lameFunc(){
/* varOne is effected at the higher level whether or not `var` is declared
above as in `varOne = 1` or `var varOne = 1` */
varOne = 'Something';
return varOne;
}
Additionally, if you declare a variable outside of event like var someInputVal = document.getElementById('someInput').value;
, then lets say you want to get the value onclick of an Element. You would want the var
declared within the Element.onclick = function(){/* in here */}
because the input may have changed before you clicked on Element
. It may be okay to declare var someInput = document.getElementById('someInput');
outside of the function that handles your Event, if the Element doesn't become undefined
then you can access the like:
var doc = document, bod = doc.body;
function E(e){
return doc.getElementById(e);
}
var someInput = E('someInput'), someInputVal = someInput.value;
E('clickButton').onclick = function(){
console.log(someInputVal); // will not be what document.getElementById('someInput').value is if it was changed before clicking
var declared = someInput.value;
console.log(declared);
}
Declaring variables at the top helps you avoid situations like this:
function outer() {
var i = 50;
function inner() {
alert(i);
var i= 30;
}
inner();
}
outer();
Many people would expect the alert to show 50
, and they would be surprised to see undefined
. That's because the i
variable is declared within the inner
function, but it isn't initialized until after the alert
. So it has full function scope, even though it's declared after its initial use.
Declare variables at the top of the function as a means of documenting all variables used in one place.
It also avoids confusion resulting from someone imagining that a variable is block-scoped when it is in fact not, as in the following:
var i=0;
if (true) {
var i=1;
}
// what is i? C programmer might imagine it's 0.
If variables are also being initialized at declaration time, putting the declarations at the top avoids potential problems with the timing of the initialization:
console.log(foo);
var foo = 1;
In this case, foo
is hoisted so it is declared at the time of the console.log
, but has not yet been initialized. So this is effectively like
var foo;
console.log(foo); // no ReferenceError, but undefined
foo = 1;
From my point of view, as javascript do not have block scope, declaring all variables on top of the function makes you spot easier variables you do not have to use as you can reuse an other.
Example :
function test(){
var pages = [
'www.stackoverflow.com',
'www.google.com'
];
var users = [
'John',
'Bob'
];
for (var page = 0; page < pages.length; page++) {
console.log(pages[page]);
};
for (var user = 0; user < users.length; user++) {
console.log(users[user]);
};
}
Can be changed to :
function test(){
var index, pages, users;
pages = [
'www.stackoverflow.com',
'www.google.com'
];
users = [
'John',
'Bob'
];
for (index = 0; index < pages.length; index++) {
console.log(pages[index]);
};
for (index = 0; index < users.length; index++) {
console.log(users[index]);
};
}
And save one variable space from the memory.
In such a small function the main point may not be visible, but imagine a whole project with thousand lines of code. This may make your code run faster.