Although arrays in JavaScript are objects, there are no good reasons to use

the [`for in loop`](#object.forinloop) in for iteration on them. In fact, there

are a number of good reasons **against** the use of `for in` on arrays.

Because the `for in` loop enumerates all the properties that are on the prototype

chain and because the only way to exclude those properties is to use

[`hasOwnProperty`](#object.hasownproperty), it is already up to **twenty times**

slower than a normal `for` loop.

In order to achieve the best performance when iterating over arrays, it is best

to use the classic `for` loop.

var list = [1, 2, 3, 4, 5, ...... 100000000];

for(var i = 0, l = list.length; i < l; i++) {

console.log(list[i]);

}

There is one extra catch in the above example, which is the caching of the

length of the array via `l = list.length`.

Although the `length` property is defined on the array itself, there is still an

overhead for doing the lookup on each iteration of the loop. And while recent

JavaScript engines **may** apply optimization in this case, there is no way of

telling whether the code will run on one of these newer engines or not.

In fact, leaving out the caching may result in the loop being only **half as

fast** as with the cached length.

While the *getter* of the `length` property simply returns the number of

elements that are contained in the array, the *setter* can be used to

**truncate** the array.

var foo = [1, 2, 3, 4, 5, 6];

foo.length = 3;

foo; // [1, 2, 3]

foo.length = 6;

foo; // [1, 2, 3]

Assigning a smaller length does truncate the array, but increasing the length

does not have any effect on the array.

For the best performance, it is recommended to always use the plain `for` loop

and cache the `length` property. The use of `for in` on an array is a sign of

badly written code that is prone to bugs and bad performance.

In short, it's *impossible* to delete global variables, functions and some other

stuff in JavaScript which have a `DontDelete` attribute set.

When a variable or a function is defined in a global

or a [function scope](#function.scopes) it is a property of either

Activation object or Global object. Such properties have a set of attributes,

one of these is `DontDelete`. Variable and function declarations in global

and function code always create properties with `DontDelete`, therefore

cannot be deleted.

// global variable:

var a = 1; // DontDelete is set

delete a; // false

a; // 1

// normal function:

function f() {} // DontDelete is set

delete f; // false

typeof f; // "function"

// reassigning doesn't help:

f = 1;

delete f; // false

f; // 1

There are things which can be deleted normally: these are explicitly set

properties.

// explicitly set property:

var obj = {x: 1};

obj.y = 2;

delete obj.x; // true

delete obj.y; // true

obj.x; // undefined

obj.y; // undefined

In the example above `obj.x` and `obj.y` can be deleted because they have no

`DontDelete` atribute. That's why an example below works too.

// this works fine, except for IE:

var GLOBAL_OBJECT = this;

GLOBAL_OBJECT.a = 1;

a === GLOBAL_OBJECT.a; // true - just a global var

delete GLOBAL_OBJECT.a; // true

GLOBAL_OBJECT.a; // undefined

Here we use a trick to delete `a`. [`this`](#function.this) here refers

to the Global object and we explicitly declare variable `a` as it's property

which allows us to delete it.

IE (at least 6-8) has some bugs, so code above doesn't work.

Functions' normal arguments, [`arguments` object](#function.arguments)

and built-in properties also have `DontDelete` set.

// function arguments and properties:

(function (x) {

delete arguments; // false

typeof arguments; // "object"

delete x; // false

x; // 1

function f(){}

delete f.length; // false

typeof f.length; // "number"

})(1);

Behaviour of `delete` operator can be unpredictable for hosted objects. Due to

specification, host objects are allowed to implement any kind of behavior.

`delete` operator often has an unexpected behaviour and can be safely used

only for dealing with explicitly set properties on normal objects.

The `eval` function will execute a string of JavaScript code in the local scope.

var foo = 1;

function test() {

var foo = 2;

eval('foo = 3');

return foo;

}

test(); // 3

foo; // 1

However, `eval` only executes in the local scope when it is being called

**directly** *and* when the name of the called function is actually `eval`.

var foo = 1;

function test() {

var foo = 2;

var bar = eval;

bar('foo = 3');

return foo;

}

test(); // 2

foo; // 3

The use of `eval` should be avoided at **all costs**. 99.9% of its "uses" can be

achieved **without** it.

The [timeout functions](#other.timeouts) `setTimeout` and `setInterval` can both

take a string as their first argument. This string will **always** get executed

in the global scope since `eval` is not being called directly in that case.

`eval` also is a security problem. Because it executes **any** code given to it,

it should **never** be used with strings of unknown or untrusted origins.

`eval` should never be used. Any code that makes use of it is to be questioned in

its workings, performance and security. In case something requires `eval` in

order to work, it should **not** be used in the first place.

A *better design* should be used, that does not require the use of `eval`.

Although JavaScript has C style syntax, it does **not** enforce the use of

semicolons in the source code, so it is possible to omit them.

JavaScript is not a semicolon-less language. In fact, it needs the

semicolons in order to understand the source code. Therefore, the JavaScript

parser **automatically** inserts them whenever it encounters a parse

error due to a missing semicolon.

var foo = function() {

} // parse error, semicolon expected

test()

Insertion happens, and the parser tries again.

var foo = function() {

}; // no error, parser continues

test()

The automatic insertion of semicolon is considered to be one of **biggest**

design flaws in the language because it *can* change the behavior of code.

The code below has no semicolons in it, so it is up to the parser to decide where

to insert them.

(function(window, undefined) {

function test(options) {

log('testing!')

(options.list || []).forEach(function(i) {

})

options.value.test(

'long string to pass here',

'and another long string to pass'

)

return

{

foo: function() {}

}

}

window.test = test

})(window)

(function(window) {

window.someLibrary = {}

})(window)

Below is the result of the parser's "guessing" game.

(function(window, undefined) {

function test(options) {

// Not inserted, lines got merged

log('testing!')(options.list || []).forEach(function(i) {

}); // <- inserted

options.value.test(

'long string to pass here',

'and another long string to pass'

); // <- inserted

return; // <- inserted, breaks the return statement

{ // treated as a block

// a label and a single expression statement

foo: function() {}

}; // <- inserted

}

window.test = test; // <- inserted

// The lines got merged again

})(window)(function(window) {

window.someLibrary = {}; // <- inserted

})(window); //<- inserted

The parser drastically changed the behavior of the code above. In certain cases,

it does the **wrong thing**.

In case of a leading parenthesis, the parser will **not** insert a semicolon.

log('testing!')

(options.list || []).forEach(function(i) {})

This code gets transformed into one line.

log('testing!')(options.list || []).forEach(function(i) {})

Chances are **very** high that `log` does **not** return a function; therefore,

the above will yield a `TypeError` stating that `undefined is not a function`.

It is highly recommended to **never** omit semicolons; it is also advocated to

keep braces on the same line with their corresponding statements and to never omit

them for one single-line `if` / `else` statements. Both of these measures will

not only improve the consistency of the code, but they will also prevent the

JavaScript parser from changing its behavior.