Dato che il costruttore `Array` è ambiguo riguardo a come esso gestisca i suoi

parametri, si consiglia calorosamente di usare l'array letterale (notazione `[]`)

quando si creano array.

[1, 2, 3]; // Risultato: [1, 2, 3]

new Array(1, 2, 3); // Risultato: [1, 2, 3]

[3]; // Risultato: [3]

new Array(3); // Risultato: []

new Array('3') // Risultato: ['3']

Nei casi in cui c'è solo un argomento passato al costruttore `Array` e quando

l'argomento è un `Number`, il costruttore ritornerà un nuovo array *frammentato*

con la proprietà `length` impostata al valore dell'argomento. Si noti

che in questo modo **solo** la proprietà `length` del nuovo array verrà impostata,

mentre gli indici dell'array non verranno inizializzati.

var arr = new Array(3);

arr[1]; // undefined

1 in arr; // false, l'indice non è stato impostato

Essere in grado di impostare la lunghezza dell'array in anticipo è utile soltanto

in poche situazioni, come ad esempio la ripetizione di una stringa, nel cui caso

si eviterebbe l'uso di un ciclo.

new Array(count + 1).join(stringToRepeat);

I letterali sono da preferirsi al costruttore Array. Sono più concisi, hanno una

sintassi più chiara ed incrementano la leggibilità del codice.

Sebbene gli array in JavaScript siano oggetti, non ci sono valide ragioni

per usare il ciclo [`for in`](#object.forinloop). Infatti, ci sono varie

buone ragioni per **evitare** l'utilizzo di `for in` con gli array.

Dato che il ciclo `for in` enumera tutte le proprietà che sono presenti nella

catena di prototipi, e dal momento che il solo modo per escludere queste

proprietà è quello di usare [`hasOwnProperty`](#object.hasownproperty),

esso è già **venti volte** più lento di un normale ciclo `for`.

Per poter ottenere la miglior performance durante l'iterazione degli array,

è meglio usare il classico ciclo `for`.

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

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

console.log(list[i]);

}

In questo esempio c'è un ulteriore particolare da notare, che è il caching

della lunghezza dell'array tramite `l = list.length`.

Sebbene la proprietà `length` sia definita nell'array stesso, c'è ancora un

sovraccarico di lavoro dato dal fatto che deve essere ricercata ad ogni

iterazione del ciclo. E mentre i motori JavaScript recenti **potrebbero**

applicare delle ottimizzazioni in questo caso, non c'è modo di dire se il

codice verrà eseguito su uno di questi nuovi motori oppure no.

Infatti, l'omissione della parte di caching può risultare in un ciclo eseguito

soltanto alla **metà della velocità** con cui potrebbe essere eseguito facendo

il caching della lunghezza.

Mentre il *getter* della proprietà `length` ritorna semplicemente il numero di

elementi che sono contenuti nell'array, il *setter* può essere usato per

**troncare** l'array.

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

foo.length = 3;

foo; // [1, 2, 3]

foo.length = 6;

foo.push(4);

foo; // [1, 2, 3, undefined, undefined, undefined, 4]

Assegnando una lunghezza più piccola si tronca l'array. Incrementandola si

crea un array frammentato.

Per la miglior performance, si raccomanda di usare sempre il ciclo `for`

classico e fare il caching della proprietà `length`. L'uso di `for in` su di

un array è segno di un codice scritto male che è suscettibile a bug e pessima

performance.

In breve, è *impossibile* eliminare variabili globali, funzioni e qualche

altra cosa in JavaScript che ha l'attributo `DontDelete` impostato.

Quando una variabile o una funzione viene definita in un scope globale o

[funzione](#function.scopes), essa è una proprietà dell'oggetto Activation

o dell'oggetto Global. Queste proprietà hanno un set di attributi, tra i quali

`DontDelete`. Dichiarazioni di variabile o funzione nel codice globale o

funzione, creano sempre proprietà con `DontDelete`, e quindi non possono essere

eliminate.

// variabile globale:

var a = 1; // DontDelete è impostato

delete a; // false

a; // 1

// funzione normale:

function f() {} // DontDelete è impostato

delete f; // false

typeof f; // "function"

// la riassegnazione non aiuta:

f = 1;

delete f; // false

f; // 1

Proprietà esplicitamente impostate possono essere eliminate normalmente.

// proprietà impostata esplicitamente:

var obj = {x: 1};

obj.y = 2;

delete obj.x; // true

delete obj.y; // true

obj.x; // undefined

obj.y; // undefined

Nel codice qui sopra, `obj.x` e `obj.y` possono essere eliminate perché

non hanno l'attributo `DontDelete`. Ecco perché anche l'esempio seguente

funziona.

// questo funziona, tranne che per IE:

var GLOBAL_OBJECT = this;

GLOBAL_OBJECT.a = 1;

a === GLOBAL_OBJECT.a; // true - solo una variabile globale

delete GLOBAL_OBJECT.a; // true

GLOBAL_OBJECT.a; // undefined

Qui usiamo un trucco per eliminare `a`. [`this`](#function.this) qui fa

riferimento all'oggetto Global e noi dichiariamo esplicitamente la

variabile `a` come sua proprietà, il che ci permette di eliminarla.

IE (almeno 6-8) ha alcuni bug, quindi il codice precedente non funziona.

Anche i normali argomenti delle funzioni, gli

[oggetti `arguments`](#function.arguments) e le proprietà interne hanno

`DontDelete` impostato.

// argomenti funzione e proprietà:

(function (x) {

delete arguments; // false

typeof arguments; // "object"

delete x; // false

x; // 1

function f(){}

delete f.length; // false

typeof f.length; // "number"

})(1);

Il comportamento dell'operatore `delete` può essere inaspettato con gli oggetti

non nativi. A causa delle specifiche, agli oggetti non nativi è permesso di

implementare qualsiasi tipo di funzionalità.

L'operatore `delete` spesso ha un comportamento inaspettato e può solo essere

usato con sicurezza per eliminare proprietà esplicitamente impostate in oggetti

normali.

La funzione `eval` eseguirà una stringa di codice JavaScript nello scope locale.

var foo = 1;

function test() {

var foo = 2;

eval('foo = 3');

return foo;

}

test(); // 3

foo; // 1

Comunque, `eval` esegue solo nello scope locale quando viene chiamata

direttamente *e* quando il nome della funzione chiamata è `eval`.

var foo = 1;

function test() {

var foo = 2;

var bar = eval;

bar('foo = 3');

return foo;

}

test(); // 2

foo; // 3

L'uso di `eval` dovrebbe essere evitato. Il 99.9% dei suoi "utilizzi" può

essere ottenuto **senza** di essa.

Le [funzioni di timeout](#other.timeouts) `setTimeout` e `setInterval` possono

entrambe accettare una stringa come loro primo argomento. Questa stringa verrà

**sempre** eseguita nello scope globale dato che `eval` non viene chiamato

direttamente in questo caso.

`eval` è anche un problema di sicurezza, perché essa esegue **qualsiasi**

codice le viene passato. Non si dovrebbe **mai** usare con stringhe di origine

sconosciuta o inaffidabile.

`eval` non dovrebbe mai essere usata. Qualsiasi codice che ne faccia uso dovrebbe

essere messo in discussione sotto l'aspetto della funzionalità, della performance

e della sicurezza. Se qualcosa richiede `eval` per poter funzionare, allora **non**

dovrebbe essere usato in primo luogo, ma si dovrebbe prevedere una

*miglior progettazione* che non richieda l'uso di `eval`.

Sebbene JavaScript utilizzi lo stile di sintassi del C, esso **non**

obbliga l'uso dei punti-e-virgola nel codice sorgente, perciò è possibile

ometterli.

Detto questo, JavaScript non è un linguaggio che fa a meno dei punti-e-virgola.

Infatti, esso necessita di punti-e-virgola per poter comprendere il codice

sorgente. Quindi, il parser del JavaScript li inserisce **automaticamente**

ogni volta che incontra un errore di analisi dato dalla mancanza di un

punto-e-virgola.

var foo = function() {

} // errore di analisi, atteso punto-e-virgola

test()

Quindi avviene l'inserimento, ed il parser prova nuovamente.

var foo = function() {

}; // nessun errore, il parser continua

test()

L'inserimento automatico dei punti-e-virgola è considerato essere uno dei

**più grandi** errori di progettazione del linguaggio, perché *può*

modificare il comportamento del codice.

Il codice qui sotto non ha punti-e-virgola, quindi sta al parser decidere dove

inserirli.

(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)

Di seguito il risultato del gioco da "indovino" del parser.

(function(window, undefined) {

function test(options) {

// Non inserito, linee unite

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

}); // <- inserito

options.value.test(

'long string to pass here',

'and another long string to pass'

); // <- inserito

return; // <- inserito, invalida l'istruzione return

{ // trattato come un blocco

// un'etichetta e una singola espressione

foo: function() {}

}; // <- inserito

}

window.test = test; // <- inserito

// Le linee vengono unite nuovamente

})(window)(function(window) {

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

})(window); //<- inserito

Il parser ha drasticamente modificato il comportamento del codice. In alcuni casi,

questo porta ad eseguire **cose sbagliate**.

Nel caso di parentesi ad inizio riga, il parser **non** inserirà un punto-e-virgola.

log('testing!')

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

Questo codice viene trasformato in una sola linea.

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

Le possibilità che `log` **non** ritorni una funzione sono **veramente** alte,

perciò il codice qui sopra porterà ad un `TypeError` dichiarando che

`undefined is not a function` (undefined non è una funzione).

&Egrave; fortemente raccomandato di non omettere **mai** i punti-e-virgola.

Si raccomanda anche di mantenere le parentesi sulla stessa linea della

corrispondente istruzione, e di non ometterle mai in istruzioni `if` / `else`

a linea singola. Queste misure precauzionali non solo miglioreranno la

consistenza del codice, ma preverranno anche che il parser JavaScript

modifichi il comportamento del codice in modo inaspettato.