È un if con un modello continuo per evitare un numero eccessivo di nidificazione durante l'iterazione su proprietà in Javascript?

Question

Io di solito uso questo modello per iterare su proprietà degli oggetti:

for(var property in object) { 
    if(object.hasOwnProperty(property)) { 
     ... 
    } 
} 

Non mi piace questo rientro eccessivo e di recente è stato sottolineato a me che ho potuto sbarazzarsi di esso in questo modo:

for(var property in object) { 
    if(!object.hasOwnProperty(property)) { 
     continue; 
    } 

    ... 
} 

Mi piace perché non introduce il livello extra di indentazione. Questo modello va bene o ci sono modi migliori?

Answer 1

Io personalmente preferisco:

for(var property in object) if(object.hasOwnProperty(property)) { 
    ... 
} 

Non v'è alcun ulteriore livello di rientro perché for, if, ecc avrà l'istruzione successiva se si lascia fuori le parentesi graffe. Poiché abbiamo inserito tutto il nostro codice nel blocco if hasOwnProperty, non sono necessarie parentesi per l'istruzione for.

Essenzialmente è equivalente a:

for(var property in object) { 
    if(object.hasOwnProperty(property)) { 
    ... 
    } else { 
     continue; 
    } 
} 

Answer 2

Syntacticly Io preferirei qualcosa di simile

function own(obj) { 
    var ownprops = {}; 
    for (var prop in obj) 
    if (obj.hasOwnProperty(prop)) ownprops[prop] = 1; 

    return ownprops; 
} 

for (var property in own(object)) { 
//code 
} 

sembra bello, ma comporta due anelli per lo stesso oggetto, non abbastanza le prestazioni saggio.

L'altro modo per farlo è functionaly

function foreach(obj, func, thisp) { 
    for (var prop in obj) 
    if (obj.hasOwnProperty(prop)) func.call(thisp, obj[prop], prop); 
} 

foreach(object, function(val, key) { 
    //code 
}); 

Solo un loop, ma una funzione viene chiamata per ogni iterazione, che non è grande prestazione saggio ma migliore della precedente soluzione. Si noti che clobbers anche il valore di this, ma è possibile passare esplicitamente tale valore come terzo argomento opzionale.

Solo alcune alternative. Il modo in cui lo stai facendo, e il modo in cui spiega Daniel va bene, e senza compromessi sulle prestazioni.

Inoltre, vorrei far notare che non si hanno di rientrare il codice per ogni singola parentesi graffa ...

Answer 3

Un fattore dipende dal fatto che si ascolta Douglas Crockford. Nel suo libro, JavaScript: The Good Parts, si aggiunge continue con le parti errate.

"Non ho mai visto un pezzo di codice che non è stato migliorato refactoring per rimuovere l'istruzione continua." - Douglas Crockford, JavaScript: le parti buone

Come Tim Giù menzionato nel suo commento, Crockford dà nessuna ragione nel libro per spiegare il motivo per cui continue dovrebbe essere evitato. Ma su his website dice, "Tende ad oscurare il flusso di controllo della funzione." Cito solo l'opinione di Crockford poiché molti lo considerano un'autorità.

Personalmente non vedo alcun problema con il modo in cui è stato codificato il loop, soprattutto perché lo continue appare nella parte superiore dove non sarà facilmente trascurato. Stai lavorando con un team di sviluppatori?Hanno una buona comprensione di ciò che fa continue? Avete un documento di convenzioni sul codice che parla di come gestire il nesting profondo delle dichiarazioni?

Answer 4

McConnel:

Un anello con molte pause può indicare pensiero chiaro sulla struttura del loop o il suo ruolo nel codice circostante . Interruzioni eccessive Gli incrementi spesso indicano che il ciclo potrebbe essere espresso in modo più chiaro come una serie di loop . L'uso della pausa elimina la possibilità di trattare il ciclo come una scatola nera. Controlla una condizione di uscita del loop con una dichiarazione per semplificare i tuoi loop. "break" obbliga la persona che legge il codice a guardare dentro per capire il controllo del ciclo , rendendo il ciclo più difficile da capire.

Dijkstra:

funzioni come pausa tendono a sabotare i benefici di strutturato programmazione, e prevenire il programmatore dalla comprensione del programma di come una composizione di unità indipendenti

I loop con continue possono essere presi in considerazione in questo modulo e quindi il loop può essere trattato come una scatola nera. Crawford ha torto. Le pause hanno un odore, ma continua è buono.

ulteriore analisi: http://sites.google.com/site/dustingetz/dev/break-and-continue