5

Nel libro di modelli di JS Design di Stefanov, scrive "si usa un'istruzione var e si dichiarano più variabili delimitate da virgole", quindi viene fornito un esempio del modello "var singolo" come segue:Svantaggi di "pattern var singolo" di Javascript

function func() { 
    var a = 1, 
     b = 2, 
     sum = a + b, 
     myobject = {}, 
     i, 
     j; 

Stefanov scrive inoltre:

  • "E 'una buona pratica per inizializzare anche la variabile con un valore iniziale al momento si dichiara."
  • "Puoi anche fare un po 'di lavoro effettivo al momento della dichiarazione, come nel caso di sum = a + b nel codice precedente."

Ora ho qualche codice come segue, dichiarando lo stesso numero di variabili con il singolo var pattern, ma facendo un po 'più di "lavoro effettivo al momento della dichiarazione" abbastanza:

var html = '{purchaseQty}<br>FR:&nbsp; {fromLoc}' 
    ,tpl = new Ext.XTemplate(html) 
    ,srcReqLoc = record.get('SRC_REQUEST_LOC').trim() 
    ,srcSupLoc = record.get('SRC_SUP_LOC').trim() 
    ,fromLoc = srcReqLoc ? srcReqLoc : srcSupLoc 
    ,tplCfg = { 
     purchaseQty: purchaseQty 
     ,fromLoc: fromLoc 
    }; 

Quali sono gli svantaggi di fare troppo "lavoro effettivo al momento della dichiarazione"? BTW Non considero questo un duplicato esatto di Javascript single var pattern. Am I overloading it? perché sto chiedendo svantaggi generali, piuttosto che cosa potrebbe essere sbagliato solo con il mio codice.

Penso di poter vedere che uno svantaggio generale sarebbe l'incapacità di controllare gli errori, ad esempio dove nel mio esempio chiamo trim() sulle stringhe attese da record.get, ma se invece viene restituito undefined, la "can il metodo 't call su oggetto non definito' (o qualunque cosa sia;) verrà lanciato. Qualcuno può pensare ad altro?

+0

Per il problema con 'trim()' è sempre possibile scrivere la propria funzione di assetto che controlla se ciò che è passato ad esso è una stringa o meno. – slebetman

+3

@slebetman - Non hai bisogno di una funzione: '(record.get ('SRC_SUP_LOC') ||" "). Trim()' (assumendo, come da domanda, che '.get()' restituisca o un stringa o non definito/null). – nnnnnn

risposta

4

Ha senso dichiarare tutte le variabili nella parte superiore dell'ambito, ovvero all'inizio di una funzione o all'inizio del codice globale. Sono d'accordo.

Per quanto riguarda i valori iniziali al momento della dichiarazione, considero questo come una linea guida. In generale è è un buon piano, e certamente funziona per valori semplici, ma a volte il valore iniziale non è noto fino a dopo alcuni calcoli più complicati - nel qual caso non fornirei un valore predefinito che non viene mai usato solo per il bene di fornire un certo valore. E a volte diventa troppo disordinato.

Inoltre, non darei le variabili dell'indice di ciclo un valore iniziale al momento della dichiarazione: per me è molto più chiaro assegnare il valore all'inizio del ciclo.

Come già sottolineato, se è necessario gestire le eccezioni e così via, è necessario farlo anche in seguito nella funzione.

Basta usare un po 'di buon senso: se hai un sacco di variabili potresti trovare che la tua istruzione var diventa un po' illeggibile, quindi puoi spostare parte dell'inizializzazione in un secondo momento nella funzione.

Per me il tuo codice di esempio è OK, ma se avessi bisogno di aggiungere molto di più ad esso sarebbe un po 'difficile da leggere perché con quel tanto codice in un blocco denso non riesco a selezionare i nomi delle variabili come facilmente , ma - e questo è, ovviamente, una questione di gusto - è possibile aggiungere un po 'di spazio bianco:

var html  = '{purchaseQty}<br>FR:&nbsp; {fromLoc}' 
    ,tpl  = new Ext.XTemplate(html) 

    ,srcReqLoc = record.get('SRC_REQUEST_LOC').trim() 
    ,srcSupLoc = record.get('SRC_SUP_LOC').trim()  
    ,fromLoc = srcReqLoc ? srcReqLoc : srcSupLoc 

    ,tplCfg = { 
     purchaseQty: purchaseQty 
     ,fromLoc: fromLoc 
    }; 

5

Personalmente collaboro con Douglas Crockford (anche se apprezzo quelli che non lo fanno), che dichiarare i vars nella parte superiore di una funzione ha più senso perché JavaScript non ha scope di blocco.

Dal JSLint site:

In linguaggi con ambito blocco, si raccomanda di solito che variabili siano dichiarate presso il sito del primo utilizzo. Ma poiché JavaScript non ha scope di blocco, è più saggio dichiarare tutte le variabili di una funzione nella parte superiore della funzione. Si consiglia di utilizzare un'unica istruzione var per funzione.

L'unico svantaggio è che il codice sarà meno leggibile per qualcuno proveniente da uno sfondo C o C.

Sono diffidente che potrei sembrare un fanboy di Crockford qui, ma lo farei recommend this talk on coding style e perché a volte il tuo cervello dovrebbe governare il tuo cuore con la struttura del codice (a seconda della lingua).

+2

+1 per menzionare "JavaScript, stile di programmazione e il tuo cervello". Adoro quel discorso :-) –

+1

Non preoccuparti di sembrare un fan di Crockford con me. Ho scoperto JSON seguendo un link nel suo sig su comp.lang.javascript * nel 2003 * –

0

(Allineare i = segni, o variabili correlate di gruppo con righe vuote, o entrambi.) Dato che questo è abbastanza vecchio e non è più completamente pertinente, è utile segnalare alle persone che vengono qui dal mondo es6 che ora abbiamo scope di blocco ing.

Il sollevamento mette comunque tutte le variabili var dichiarate nella parte superiore dell'ambito della funzione, ma a volte si realizza come si codifica che una variabile viene utilizzata solo in un determinato blocco, nel qual caso è preferibile, o anche se la variabile ha vinto cambiare il riferimento, in tal caso const è l'idea migliore.