2012-04-11 14 views
14

"use strict"; sembra fantastico, e ci piacerebbe davvero usarlo nel nostro negozio. Tuttavia, vogliamo solo che noi (gli sviluppatori) possiamo trovare problemi di rigore; Vogliamo davvero NON fare in modo che il nostro sito si rompa per i nostri attuali clienti quando funzionava bene prima.È "sicuro uso" sicuro per i siti live?

Ora, potremmo usare un po 'di logica server-side per raggiungere questo obiettivo:

{% if debug %}<script>"use strict";</script>{% endif %} 

... tranne che "use strict" opera su una base di file per file, in modo che non lo farà funziona davvero (beh, a meno che non iniziamo l'elaborazione lato server di tutti i nostri file JS).

Quindi, la mia domanda è: fare tutte le funzioni "usa controlli rigorosi" per essere controllati quando la pagina viene caricata, o è possibile utilizzare "strict" per trovare errori dopo che la pagina è stata caricata? Se è il primo, possiamo semplicemente usare "use strict" e smettere di preoccuparci, perché caricheremo il nostro sito in fase di sviluppo prima di caricarlo dal vivo. Tuttavia, se è quest'ultimo, ci sembra di essere sfortunati, dal momento che non possiamo testare tutte le possibili condizioni di esecuzione (e ancora una volta, non vogliamo fare errori per i nostri utenti quando prima non c'erano errori).

+1

Puoi anche utilizzare un buon JSLint durante le fasi finali di sviluppo per assicurarti che il tuo codice sia sicuro. – jfriend00

risposta

12

È il secondo. Mentre si trova in strict mode, un interprete Javascript può lanciare messaggi di errore in fase di esecuzione, che non vengono lanciati in modalità non rigida.

D'altra parte, la maggior parte di questi errori sono "errori buoni", il che significa che in realtà aiutano a non infrangere il codice.

Per esempio

function foo() { 
    "use strict"; 
    bar = true; 
} 

foo(); 

Questo getterà

"ReferenceError: assignment to undeclared variable bar" 

in modalità rigorosa, che è una buona cosa. In modalità non rigida, avremmo appena creato una variabile globale chiamata bar, che probabilmente non è ciò che volevamo. Ci sono molte altre situazioni in cui strict mode impedisce al programmatore di fare qualcosa di stupido/cattivo/indesiderato e genera messaggi di errore. Ma ancora una volta, si si desidera che contenga questi errori invece di alcuni bugs.

avere un ulteriore letto su MDN

+2

Prima di tutto, grazie per la risposta; spiega totalmente le cose (e sembra che sia sfortunato).Un punto però: continuavi a dire che gli errori severi sono "* buono *", ma "buono" è altamente soggettivo. Mentre sono d'accordo che le variabili globali sono cattive, il modo in cui vedo che una pagina che in precedenza ha funzionato bene smette improvvisamente di funzionare per un cliente è MOLTO MOLTO peggio. Gli errori di severità sono solo "buoni" se impediscono gli errori dei clienti; se causano tali errori, sono peggio di nessun rigore (supponendo che il tuo obiettivo finale sia un sito di lavoro per i tuoi clienti, e non solo un codice "perfetto" astratto). – machineghost

+1

Bene come ho detto. la modalità rigorosa ti impedirà di fare cose che alla fine finiranno in peggio, forse anche in errori nascosti. Quindi preferirei sempre ottenere un errore chiaro invece di bug errati. – jAndy

6

Se ho capito bene, sì, è sicuramente possibile per la modalità rigorosa per catturare gli errori dopo che la pagina è stata caricata. Per esempio:

'use strict'; 

setTimeout(function() { 
    undefined = 42; // Causes a TypeError 
}, 1000); 

// Click here for a demo.

Che cosa si può fare è piuttosto semplice: si dovrebbe essere Minimizzando il tuo JavaScript quando si sposta alla produzione in ogni caso. Assicurati che lo 'use strict' venga rimosso durante il processo di minimizzazione.

In caso contrario, cerca di assicurarti che il tuo codice sia rigoroso e privo di errori. La modalità rigorosa di solito entra in gioco per quanto riguarda la semantica, non a causa di qualcosa di strano l'input dell'utente o anche a causa della sintassi. Non dovrebbe essere troppo difficile da catturare tutti i casi. (Ma minimizzare e rimuovere 'use strict' è una soluzione molto migliore.)