2012-02-13 8 views
5

Stavo controllando uno dei file js minificati generati dalla chiusura. Ho scoperto che ovunque io sto controllando per la parità tra una variabile e stringa come,Minificazione Javascript delle istruzioni di confronto

a == "13" || a == "40" 

chiusura sostituisce con

"13" == a || "40" == a 

Perché è fatto questa modifica? C'è qualche vantaggio in termini di prestazioni qui?

risposta

5

[UPDATE: vedere @ risposta di Giovanni, ha più senso per spiegare perché un minifier js avrebbe fatto questo, e dovrebbe essere la risposta accettata]

come concetto generale, questo è quello di evitare l'errore programmatore . Se si modifica manualmente il codice e si imposta la variabile prima e seconda costante, è possibile digitare accidentalmente:

a == '40' || a = '13' 

Oops! Abbiamo appena impostato a su '13' invece di confrontare. Mettendo la costante sulla sinistra, evitiamo questa possibilità:

'40' == a || '13' = a 

un'eccezione, perché non si può mettere una stringa costante sulla mano sinistra di un'operazione di assegnazione.

Quindi, in alcune scuole di pensiero, è consigliabile mettere sempre la costante a sinistra quando si fa il confronto di uguaglianza con una costante. Sembra che la chiusura segua quella pratica.

Queste sono chiamate "condizioni yoda".

Nota che la mia preferenza personale è in realtà di mettere la costante sulla destra nella maggior parte dei casi, perché il codice tende a leggere meglio, quindi non credo che il compromesso sia abbastanza buono. Ma vedo la logica dietro le condizioni di yoda.

+0

Questo non spiega perché un compressore potrebbe farlo però. OT: hanno effettivamente eliminato il [thread sulle condizioni Yoda] (http://webcache.googleusercontent.com/search?q=cache:stackoverflow.com/questions/2349378/new-programming-jargon-you-coined+jargon+ coniata) ?! – user123444555621

+0

Il compressore utilizza le migliori pratiche ovunque sia possibile, solo perché è possibile. (Offchance che qualcuno modifica la versione minificata forse?) –

+0

Inoltre, non ero a conoscenza di quel thread sulle condizioni della yoda. Ho appena sentito questo descritto così prima. –

9

Questo è un vantaggio di compressione gzip minore. Se hai "x == 1" e "1 == x" il compilatore lo cambia in "1 == x" in entrambi i casi e ottieni un codice più regolare che comprime meglio. La vittoria è così piccola che ho preso in considerazione l'eliminazione del codice e il salvataggio dei cicli della CPU, ma per ora è attivo. Non ha nulla a che fare con la prevenzione degli errori del programmatore in quanto non cambierà mai "x = 2" in "2 = x" in quanto ciò cambierebbe il significato del programma.

+1

Ha senso. OP (@ user843241) dovrebbe cambiare questo alla risposta accettata. Cancellerei la mia risposta, ma non so se sarebbe kosher. Anche se solo per la cronaca, le Condizioni Yoda non dicono mai nulla sull'ordine degli operandi in missione; ovviamente non cambieresti mai "x = 2" in "2 = x". Le condizioni di Yoda riguardano solo l'ordine degli operandi sul paragone dell'uguaglianza. –