Che cosa fa “use strict” in JavaScript e qual è il ragionamento che sta dietro?

Recentemente, ho eseguito un po ‘del mio codice JavaScript tramite JSLint di Crockford, e ha dato il seguente errore:

Problema alla riga 1 carattere 1: manca la frase “use strict“.

Facendo qualche ricerca, ho capito che alcune persone aggiungono "use strict"; nel loro codice JavaScript. Una volta aggiunta la dichiarazione, l’errore ha smesso di apparire. Sfortunatamente, Google non ha rivelato gran parte della storia dietro questa dichiarazione di stringa. Certamente deve avere qualcosa a che fare con il modo in cui il JavaScript viene interpretato dal browser, ma non ho idea di quale sarebbe l’effetto.

Quindi cos’è "use strict"; tutto ciò, cosa implica, ed è ancora rilevante?

Qualcuno dei browser attuali risponde "use strict"; stringa o è per uso futuro?

    Questo articolo sulla modalità Strict Javascript potrebbe interessarti: John Resig – ECMAScript 5 Modalità rigorosa, JSON e altro

    Per citare alcune parti interessanti:

    La modalità rigorosa è una nuova funzionalità di ECMAScript 5 che consente di posizionare un programma o una funzione in un contesto operativo “rigoroso”. Questo contesto rigoroso impedisce che alcune azioni vengano prese e genera più eccezioni.

    E:

    La modalità rigorosa aiuta in un paio di modi:

    • Cattura alcuni comuni blooper in codice, generando eccezioni.
    • Previene, o genera errori, quando vengono intraprese azioni relativamente “non sicure” (come ottenere l’accesso all’object globale).
    • Distriggers le funzionalità che sono confuse o mal concepite.

    Nota inoltre che puoi applicare la “modalità rigorosa” all’intero file … Oppure puoi usarlo solo per una funzione specifica (continuando a citare l’articolo di John Resig) :

     // Non-strict code... (function(){ "use strict"; // Define your library strictly... })(); // Non-strict code... 

    Quale potrebbe essere utile se devi mescolare il vecchio e il nuovo codice 😉

    Quindi, suppongo che sia un po ‘come "use strict" che puoi usare in Perl (da cui il nome?) : Ti aiuta a fare meno errori, rilevando più cose che potrebbero portare a rotture.

    Attualmente è supportato da tutti i principali browser (barra IE 9 e seguenti) .

    È una nuova funzionalità di ECMAScript 5. John Resig ha scritto un bel riassunto di questo.

    È solo una stringa che inserisci nei tuoi file JavaScript (nella parte superiore del tuo file o all’interno di una funzione) che assomiglia a questo:

     "use strict"; 

    Inserirlo nel tuo codice ora non dovrebbe causare problemi con i browser attuali in quanto è solo una stringa. Potrebbero causare problemi con il tuo codice in futuro se il tuo codice violasse il pragma. Ad esempio, se al momento hai foo = "bar" senza prima definire foo , il tuo codice inizierà a fallire … il che è una buona cosa secondo me.

    La frase "use strict"; indica al browser di utilizzare la modalità Strict, che è una serie di JavaScript ridotta e più sicura.

    Elenco delle caratteristiche (non esaustivo)

    1. Non consente le variabili globali. (Catture mancano dichiarazioni var e errori di battitura nei nomi delle variabili)

    2. Assegnazioni non riuscite silenziose generano errori in modalità rigorosa (assegnando NaN = 5; )

    3. Tentativi di eliminare proprietà non delete Object.prototype ( delete Object.prototype )

    4. Richiede che tutti i nomi di proprietà in un object letterale siano univoci ( var x = {x1: "1", x1: "2"} )

    5. I nomi dei parametri delle funzioni devono essere univoci ( function sum (x, x) {...} )

    6. Proibisce la syntax ottale ( var x = 023; alcuni sviluppatori assumono erroneamente che uno zero precedente non modifichi il numero).

    7. Proibisce la parola chiave with

    8. eval in modalità rigorosa non introduce nuove variabili

    9. Proibisce l’eliminazione di nomi semplici ( delete x; )

    10. Proibisce l’associazione o l’assegnazione dei nomi eval e gli arguments in qualsiasi forma

    11. La modalità rigorosa non alias le proprietà dell’object arguments con i parametri formali. (cioè nella function sum (a,b) { return arguments[0] + b;} Questo funziona perché gli arguments[0] sono associati a a e così via.)

    12. arguments.callee non è supportato

    [Ref: Modalità rigorosa , Mozilla Developer Network ]

    Se le persone sono preoccupate use strict potrebbe valere la pena di dare un’occhiata a questo articolo:

    ECMAScript 5 Supporto “modalità rigorosa” nei browser. Cosa significa questo?
    NovoGeek.com – Il blog di Krishna

    Parla del supporto del browser, ma soprattutto di come gestirlo in sicurezza:

     function isStrictMode(){ return !this; } /* returns false, since 'this' refers to global object and '!this' becomes false */ function isStrictMode(){ "use strict"; return !this; } /* returns true, since in strict mode the keyword 'this' does not refer to global object, unlike traditional JS. So here, 'this' is 'undefined' and '!this' becomes true. */ 

    Una parola di caucanvas, tutti voi programmatori che caricano duramente: applicare "use strict" al codice esistente può essere pericoloso! Questa cosa non è un adesivo di buon gusto, faccia felice che puoi dare uno schiaffo al codice per renderlo ‘migliore’. Con il pragma "use strict" , il browser improvvisamente LANCIA eccezioni in posti casuali che non ha mai gettato prima solo perché in quel punto stai facendo qualcosa che default / loose JavaScript consente felicemente, ma rigidi aborti su JavaScript! Potresti avere violazioni di rigore che si nascondono nelle chiamate usate raramente nel tuo codice che generano solo un’eccezione quando alla fine vengono eseguite, ad esempio nell’ambiente di produzione utilizzato dai tuoi clienti paganti!

    Se hai intenzione di fare il grande passo, è una buona idea applicare "use strict" insieme a test unitari completi e un’attività di compilazione JSHint strettamente configurata che ti darà la certezza che non c’è un angolo scuro del tuo modulo che esploderà orribilmente solo perché hai triggersto la modalità rigorosa. Oppure, hey, ecco un’altra opzione: non aggiungere "use strict" a nessuno dei tuoi codici legacy, è probabilmente più sicuro in questo modo, onestamente. DEFINITAMENTE NON aggiungere "use strict" a tutti i moduli che non possiedi o gestisci, come i moduli di terze parti.

    Penso che anche se è un animale in gabbia mortale, "use strict" può essere una buona roba, ma devi farlo bene. Il momento migliore per andare rigorosi è quando il tuo progetto è greenfield e stai partendo da zero. Configura JSHint/JSLint con tutti gli avvertimenti e le opzioni alzati così forte come la tua squadra può sopportare, ottenere una buona build / test / asserire system du jour truccato come Grunt+Karma+Chai , e solo POI iniziare a marcare tutti i tuoi nuovi moduli come "use strict" . Preparati a curare molti errori e avvertimenti. Assicurati che tutti comprendano la gravità configurando la build su FAIL se JSHint/JSLint produce violazioni.

    Il mio progetto non era un progetto greenfield quando ho adottato "use strict" . Di conseguenza, il mio IDE è pieno di segni rossi perché non ho "use strict" su metà dei miei moduli, e JSHint si lamenta di ciò. È un promemoria per me su cosa dovrei rifare in futuro. Il mio objective è quello di essere libero dal marchio rosso a causa di tutte le mie dichiarazioni "use strict" mancano, ma sono lontani anni.

    Usare 'use strict'; improvvisamente non migliora il tuo codice.

    La modalità rigorosa JavaScript è una funzionalità di ECMAScript 5 . Puoi triggersre la modalità rigorosa dichiarandola nella parte superiore del tuo script / funzione.

     'use strict'; 

    Quando un motore JavaScript vede questa direttiva , inizierà a interpretare il codice in una modalità speciale. In questa modalità, gli errori vengono generati quando determinate pratiche di codifica che potrebbero finire per essere individuate da potenziali bug vengono rilevate (che è il ragionamento alla base della modalità rigorosa).

    Considera questo esempio:

     var a = 365; var b = 030; 

    Nella loro ossessione di allineare i valori letterali numerici, lo sviluppatore ha inavvertitamente inizializzato la variabile b con un valore letterale ottale. La modalità non rigida interpreterà questo come un valore letterale numerico con valore 24 (in base 10). Tuttavia, la modalità rigorosa genererà un errore.

    Per un elenco non esaustivo di specialità in modalità rigorosa, vedere questa risposta .


    Dove dovrei usare 'use strict'; ?

    • Nella mia nuova applicazione JavaScript: assolutamente! La modalità rigorosa può essere utilizzata come informatore quando stai facendo qualcosa di stupido con il tuo codice.

    • Nel mio codice JavaScript esistente : Probabilmente no! Se il codice JavaScript esistente contiene affermazioni proibite in modalità rigorosa, l’applicazione si interromperà. Se si desidera la modalità rigorosa, è necessario essere pronti a eseguire il debug e correggere il codice esistente. Questo è il motivo per cui si usa 'use strict'; improvvisamente non migliora il tuo codice .


    Come uso la modalità rigorosa?

    1. Inserisci un 'use strict'; dichiarazione in cima al tuo script:

       // File: myscript.js 'use strict'; var a = 2; .... 

      Nota che tutto nel file myscript.js sarà interpretato in modalità rigorosa.

    2. Oppure, inserire un 'use strict'; dichiarazione in cima al tuo corpo della funzione:

       function doSomething() { 'use strict'; ... } 

      Tutto nella portata lessicale della funzione doSomething sarà interpretato in modalità rigorosa. La parola portata lessicale è importante qui. Vedi questa risposta per una spiegazione migliore.


    Quali cose sono proibite in modalità rigorosa?

    Ho trovato un buon articolo che descrive diverse cose che sono vietate in modalità rigorosa (si noti che questo non è un elenco esclusivo):

    Scopo

    Storicamente, JavaScript è stato confuso su come le funzioni sono scoped. A volte sembrano essere stati esaminati in modo statico, ma alcune funzioni li fanno comportare come se fossero a livello dinamico. Ciò è fonte di confusione, rendendo i programmi difficili da leggere e capire. L’incomprensione causa bug. È anche un problema per le prestazioni. L’ambito statico consentirebbe il binding variabile in tempo di compilazione, ma il requisito per l’ambito dinamico significa che l’associazione deve essere posticipata al runtime, che comporta una significativa riduzione delle prestazioni.

    La modalità rigorosa richiede che tutte le associazioni vincolanti vengano eseguite staticamente. Ciò significa che le funzionalità che precedentemente richiedevano il binding dinamico devono essere eliminate o modificate. Nello specifico, l’istruzione with viene eliminata e la capacità della funzione eval di manomettere l’ambiente del chiamante è severamente limitata.

    Uno dei vantaggi del codice rigoroso è che strumenti come YUI Compressor possono fare un lavoro migliore durante l’elaborazione.

    Variabili globali implicite

    JavaScript ha implicato variabili globali. Se non si dichiara esplicitamente una variabile, viene dichiarata implicitamente una variabile globale. Ciò semplifica la programmazione per i principianti perché possono trascurare alcune delle loro faccende di base. Ma rende la gestione di programmi più grandi molto più difficile e degrada in modo significativo l’affidabilità. Quindi, in modalità rigorosa, le variabili globali implicite non vengono più create. Dovresti dichiarare esplicitamente tutte le tue variabili.

    Perdita globale

    Ci sono un certo numero di situazioni che potrebbero far sì che this sia legato all’object globale. Ad esempio, se si dimentica di fornire il new prefisso quando si chiama una funzione di costruzione, il costruttore si collegherà in modo imprevisto all’object globale, quindi anziché inizializzare un nuovo object, invece, manometterà silenziosamente le variabili globali. In queste situazioni, la modalità strict lo vincolerà a undefined , il che farà sì che il costruttore lanci un’eccezione, consentendo di rilevare molto prima l’errore.

    Rumoroso Fallimento

    JavaScript ha sempre avuto proprietà di sola lettura, ma non è stato ansible crearle da soli fino a quando la funzione Object.createProperty di ES5 non ha Object.createProperty tale capacità. Se si è tentato di assegnare un valore a una proprietà di sola lettura, si sarebbe verificato un errore. Il compito non cambierebbe il valore della proprietà, ma il tuo programma procederà come se lo fosse. Questo è un rischio di integrità che può far sì che i programmi entrino in uno stato incoerente. In modalità rigorosa, il tentativo di modificare una proprietà di sola lettura genera un’eccezione.

    Octal

    La rappresentazione ottale (o base 8) dei numeri era estremamente utile quando si eseguiva la programmazione a livello macchina su macchine le cui dimensioni di parola erano un multiplo di 3. Avevi bisogno di ottale quando lavoravi con il mainframe CDC 6600, che aveva una dimensione di parola di 60 bit. Se si potesse leggere ottale, si potrebbe guardare una parola come 20 cifre. Due cifre rappresentavano il codice operativo e una cifra identificava uno degli 8 registri. Durante la transizione lenta dai codici macchina ai linguaggi di alto livello, si è pensato fosse utile per fornire forms ottali nei linguaggi di programmazione.

    In C, è stata selezionata una rappresentazione estremamente sfortunata dell’ottualità: lo zero iniziale. Quindi in C, 0100 significa 64, non 100, e 08 è un errore, non 8. Ancora più sfortunatamente, questo anacronismo è stato copiato in quasi tutte le lingue moderne, incluso JavaScript, dove è usato solo per creare errori. Non ha altro scopo. Quindi in modalità rigorosa, le forms ottali non sono più consentite.

    Et cetera

    Gli argomenti pseudo array diventano un po ‘più simili ad array in ES5. In modalità rigorosa, perde le sue proprietà di caller e caller . Ciò rende ansible passare i tuoi arguments a un codice non fidato senza rinunciare a un sacco di contesto confidenziale. Inoltre, la proprietà arguments delle funzioni viene eliminata.

    In modalità rigorosa, le chiavi duplicate in una funzione letterale generano un errore di syntax. Una funzione non può avere due parametri con lo stesso nome. Una funzione non può avere una variabile con lo stesso nome di uno dei suoi parametri. Una funzione non può delete sue variabili. Un tentativo di delete una proprietà non configurabile ora genera un’eccezione. I valori primitivi non sono implicitamente avvolti.


    Parole riservate per versioni future di JavaScript

    ECMAScript 5 aggiunge un elenco di parole riservate. Se li usi come variabili o argomenti, la modalità rigorosa genererà un errore. Le parole riservate sono:

    implements , interface , let , package , private , protected , public , static e yield


    Ulteriori letture

    • Modalità rigorosa – JavaScript | MDN
    • Supporto del browser per la modalità rigorosa
    • Passaggio alla modalità rigorosa

    Consiglio vivamente a tutti gli sviluppatori di iniziare a utilizzare la modalità rigorosa ora. Ci sono abbastanza browser che lo supportano che la modalità rigorosa ci aiuterà legittimamente a salvarci da errori che non sapevamo nemmeno che fossero nel tuo codice.

    Apparentemente, nella fase iniziale ci saranno errori che non abbiamo mai incontrato prima. Per ottenere il massimo beneficio, dobbiamo eseguire test appropriati dopo aver triggersto la modalità rigorosa per assicurarci di aver catturato tutto. Sicuramente non usiamo solo use strict nel nostro codice e assumiamo che non ci siano errori. Quindi, il churn è che è ora di iniziare a utilizzare questa caratteristica del linguaggio incredibilmente utile per scrivere codice migliore.

    Per esempio,

     var person = { name : 'xyz', position : 'abc', fullname : function () { "use strict"; return this.name; } }; 

    JSLint è un debugger scritto da Douglas Crockford. Basta incollare il tuo script e scansionerà rapidamente eventuali problemi e errori evidenti nel tuo codice.

    Vorrei offrire una risposta un po ‘più fondata che integri le altre risposte. Speravo di modificare la risposta più popolare, ma non ci sono riuscito. Ho cercato di renderlo il più completo e completo ansible.

    È ansible fare riferimento alla documentazione MDN per ulteriori informazioni.

    "use strict" una direttiva introdotta in ECMAScript 5.

    Le direttive sono simili alle dichiarazioni, ma differenti.

    • use strict non contiene parole chiave: la direttiva è una semplice espressione di espressione, che consiste in una stringa letterale speciale (in virgolette singole o doppie). I motori JavaScript, che non implementano ECMAScript 5, visualizzano semplicemente una dichiarazione di espressioni senza effetti collaterali. Si prevede che le versioni future degli standard ECMAScript introducano l’ use come una vera parola chiave; le virgolette diventerebbero quindi obsolete.
    • use strict può essere usato solo all’inizio di uno script o di una funzione, cioè deve precedere ogni altra (vera) affermazione. Non deve essere la prima istruzione in uno script di funzione: può essere preceduta da altre espressioni di istruzione costituite da stringhe letterali (e le implementazioni JavaScript possono considerarle come direttive specifiche dell’implementazione). Le dichiarazioni letterali stringa, che seguono una prima dichiarazione reale (in uno script o in una funzione) sono semplici istruzioni di espressione. Gli interpreti non devono interpretarli come direttive e non hanno alcun effetto.

    La direttiva use strict indica che il codice seguente (in uno script o una funzione) è un codice rigoroso. Il codice nel livello più alto di uno script (codice che non è in una funzione) è considerato codice rigoroso quando lo script contiene una direttiva use strict . Il contenuto di una funzione è considerato codice rigoroso quando la funzione stessa è definita in un codice rigoroso o quando la funzione contiene una direttiva use strict . Il codice passato a un metodo eval() è considerato codice rigoroso quando eval() stato chiamato da un codice rigoroso o contiene la direttiva use strict stessa.

    La modalità rigorosa di ECMAScript 5 è un sottoinsieme limitato del linguaggio JavaScript, che elimina i deficit rilevanti del linguaggio e offre un controllo degli errori più rigoroso e una maggiore sicurezza. Di seguito sono elencate le differenze tra la modalità rigorosa e la modalità normale (di cui i primi tre sono particolarmente importanti):

    • Non è ansible utilizzare l’opzione -statement in modalità rigorosa.
    • In modalità rigorosa tutte le variabili devono essere dichiarate: se si assegna un valore a un identificatore che non è stato dichiarato come variabile, funzione, parametro funzione, parametro catch-clause o proprietà Object globale, si otterrà un ReferenceError . In modalità normale l’identificatore è implicitamente dichiarato come variabile globale (come proprietà Object globale)
    • Nella modalità strict la parola chiave this ha il valore undefined in funzioni invocate come funzioni (non come metodi). (Nella modalità normale this punta sempre Object globale). Questa differenza può essere utilizzata per verificare se un’implementazione supporta la modalità rigorosa:
     var hasStrictMode = (function() { "use strict"; return this===undefined }()); 
    • Anche quando una funzione viene invocata con call() o apply in modalità strict, allora this è esattamente il valore del primo argomento call() o apply() . (Nella modalità normale, null e undefined vengono sostituiti Object globale e i valori, che non sono oggetti, vengono convertiti in oggetti.)

    • Nella modalità strict otterrai un TypeError quando tenti di assegnare proprietà readonly o di definire nuove proprietà per un object non estensibile. (In modalità normale entrambi falliscono senza messaggi di errore.)

    • In modalità rigorosa, quando si passa il codice a eval() , non è ansible dichiarare o definire variabili o funzioni nell’ambito del chiamante (poiché è ansible farlo in modalità normale). Invece, viene creato un nuovo ambito per eval() e le variabili e le funzioni rientrano in tale ambito. Tale ambito viene distrutto dopo che eval() termina l’esecuzione.
    • Nella modalità strict l’argomento-object di una funzione contiene una copia statica dei valori, che vengono passati a quella funzione. In modalità normale l’argomento-object ha un comportamento un po ‘”magico”: gli elementi dell’array e i parametri di funzione nominati fanno riferimento allo stesso valore.
    • Nella modalità strict otterrai un SyntaxError quando l’operatore di delete è seguito da un identificatore non qualificato (una variabile, una funzione o un parametro di funzione). In modalità normale l’espressione delete non farebbe nulla e verrà valutata come false .
    • Nella modalità strict otterrai un TypeError quando tenti di eliminare una proprietà non configurabile. (In modalità normale il tentativo fallisce semplicemente e l’espressione delete viene valutata su false ).
    • In modalità rigorosa viene considerato un errore sintattico quando si tenta di definire diverse proprietà con lo stesso nome per un object letterale. (In modalità normale non ci sono errori.)
    • In modalità strict è considerato un errore sintattico quando una dichiarazione di funzione ha più parametri con lo stesso nome. (In modalità normale non ci sono errori.)
    • Nella modalità strict non sono consentiti i letterali ottali (questi sono letterali che iniziano con 0x . (In modalità normale alcune implementazioni consentono letterali ottali).
    • In modalità rigorosa, gli identificatori eval e gli arguments sono trattati come parole chiave. Non è ansible modificare il loro valore, non è ansible assegnargli un valore e non è ansible utilizzarli come nomi per variabili, funzioni, parametri di funzione o identificatori di un blocco di cattura.
    • In modalità rigorosa ci sono più restrizioni sulle possibilità di esaminare lo stack delle chiamate. arguments.caller e arguments.callee causano un TypeError in una funzione in modalità rigorosa. Inoltre, alcune proprietà caller e arguments delle funzioni in modalità strict causano TypeError quando si tenta di leggerle.

    I miei due centesimi:

    Uno degli obiettivi della modalità rigorosa è consentire un più rapido debug dei problemi. Aiuta gli sviluppatori a generare eccezioni quando si verificano determinate cose sbagliate che possono causare un comportamento silenzioso e strano della tua pagina web. Nel momento in cui usiamo l’ use strict , il codice genererà errori che aiutano lo sviluppatore a risolverlo in anticipo.

    Poche cose importanti che ho imparato dopo aver usato use strict :

    Previene la dichiarazione delle variabili globali:

     var tree1Data = { name: 'Banana Tree',age: 100,leafCount: 100000}; function Tree(typeOfTree) { var age; var leafCount; age = typeOfTree.age; leafCount = typeOfTree.leafCount; nameoftree = typeOfTree.name; }; var tree1 = new Tree(tree1Data); console.log(window); 

    Ora, questo codice crea nameoftree nell’ambito globale a cui è ansible accedere usando window.nameoftree . Quando implementiamo l’ use strict il codice genererebbe un errore.

    Uncaught ReferenceError: nameoftree non è definito

    Campione

    Elimina with dichiarazione:

    with dichiarazioni non può essere minimizzato utilizzando strumenti come uglify-js . Sono anche deprecati e rimossi dalle versioni future di JavaScript.

    Campione

    Previene i duplicati:

    Quando abbiamo la proprietà duplicata, genera un’eccezione

    Uncaught SyntaxError: proprietà dei dati duplicati nel letterale dell’object non consentita in modalità rigorosa

     "use strict"; var tree1Data = { name: 'Banana Tree', age: 100, leafCount: 100000, name:'Banana Tree' }; 

    Ce ne sono alcuni di più, ma ho bisogno di acquisire più conoscenza al riguardo.

    Se utilizzi un browser rilasciato nell’ultimo anno, probabilmente supporta la modalità Strict di JavaScript. Solo i browser più vecchi prima che ECMAScript 5 diventasse lo standard attuale non lo supportano.

    Le virgolette attorno al comando assicurano che il codice funzioni ancora anche nei browser più vecchi (anche se le cose che generano un errore di syntax in modalità rigorosa generalmente causano il malfunzionamento dello script in alcuni modi difficili da rilevare in quei vecchi browser).

    La modalità rigorosa apporta diverse modifiche alla normale semantica di JavaScript:

    • elimina alcuni errori JavaScript JavaScript modificandoli per generare errori.

    • corregge gli errori che rendono difficile per i motori JavaScript eseguire ottimizzazioni.

    • proibisce alcune syntax che potrebbero essere definite nelle versioni future di ECMAScript.

    per maggiori informazioni vistit Strict Mode- Javascript

    “Usa rigorosamente”; è un’assicurazione che il programmatore non utilizzerà le proprietà libere o errate di JavaScript. È una guida, proprio come un righello ti aiuterà a fare linee rette. “Usa Strict” ti aiuterà a fare “Codifica Diretta”.

    Coloro che preferiscono non usare i righelli per fare le loro linee dritte di solito finiscono in quelle pagine per chiedere agli altri di eseguire il debug del loro codice.

    Credimi. Il sovraccarico è trascurabile rispetto al codice mal progettato. Doug Crockford, che è stato sviluppatore senior di JavaScript per diversi anni, ha un post molto interessante qui . Personalmente, mi piace tornare sul suo sito tutto il tempo per assicurarmi di non dimenticare le mie buone pratiche.

    La pratica moderna di JavaScript dovrebbe sempre evocare il “Use Strict”; pragma. L’unica ragione per cui il gruppo ECMA ha reso facoltativa la modalità “Strict” è quella di consentire ai codificatori meno esperti di accedere a JavaScript e dare quindi il tempo di adattarsi alle nuove e più sicure pratiche di codifica.

    Quando aggiungi "use strict"; , i seguenti casi generano un errore SyntaxError prima dell’esecuzione dello script:

    • Paving the way for future ECMAScript versions , using one of the newly reserved keywords (in prevision for ECMAScript 6 ): implements , interface , let , package , private , protected , public , static , and yield .

    • Declaring function in blocks

       if(a 
    • Octal syntax

       var n = 023; 
    • this point to the global object.

        function f() { "use strict"; this.a = 1; }; f(); 
    • Declaring twice the same name for a property name in an object literal

        {a: 1, b: 3, a: 7} 

      This is no longer the case in ECMAScript 6 ( bug 1041128 ).

    • Declaring two function arguments with the same name function

       f(a, b, b){} 
    • Setting a value to an undeclared variable

       function f(x){ "use strict"; var a = 12; b = a + x*35; // error! } f(); 
    • Using delete on a variable name delete myVariable;

    • Using eval or arguments as variable or function argument name

       "use strict"; arguments++; var obj = { set p(arguments) { } }; try { } catch (arguments) { } function arguments() { } 

    fonti:

    • Transitioning to strict mode on MDN

    • Strict mode on MDN

    • JavaScript's Strict Mode and Why You Should Use It on Colin J. Ihrig's blog (archived version)

    Including use strict in the beginning of your all sensitive JavaScript files from this point is a small way to be a better JavaScript programmer and avoid random variables becoming global and things change silently.

    Quoting from w3schools :

    The “use strict” Directive

    The “use strict” directive is new in JavaScript 1.8.5 (ECMAScript version 5).

    It is not a statement, but a literal expression, ignored by earlier versions of JavaScript.

    The purpose of “use strict” is to indicate that the code should be executed in “strict mode”.

    With strict mode, you can not, for example, use undeclared variables.

    Why Strict Mode?

    Strict mode makes it easier to write “secure” JavaScript.

    Strict mode changes previously accepted “bad syntax” into real errors.

    As an example, in normal JavaScript, mistyping a variable name creates a new global variable. In strict mode, this will throw an error, making it impossible to accidentally create a global variable.

    In normal JavaScript, a developer will not receive any error feedback assigning values to non-writable properties.

    In strict mode, any assignment to a non-writable property, a getter-only property, a non-existing property, a non-existing variable, or a non-existing object, will throw an error.

    Please refer to http://www.w3schools.com/js/js_strict.asp to know more

    There’s a good talk by some people who were on the ECMAScript committee: Changes to JavaScript, Part 1: ECMAScript 5″ about how incremental use of the "use strict" switch allows JavaScript implementers to clean up a lot of the dangerous features of JavaScript without suddenly breaking every website in the world.

    Of course it also talks about just what a lot of those misfeatures are (were) and how ECMAScript 5 fixes them.

    "use strict" makes JavaScript code to run in strict mode , which basically means everything needs to be defined before use. The main reason for using strict mode is to avoid accidental global uses of undefined methods.

    Also in strict mode, things run faster, some warnings or silent warnings throw fatal errors, it’s better to always use it to make a neater code.

    "use strict" is widely needed to be used in ECMA5, in ECMA6 it’s part of JavaScript by default , so it doesn’t need to be added if you’re using ES6.

    Look at these statements and examples from MDN:

    The “use strict” Directive
    The “use strict” directive is new in JavaScript 1.8.5 (ECMAScript version 5). It is not a statement, but a literal expression, ignored by earlier versions of JavaScript. The purpose of “use strict” is to indicate that the code should be executed in “strict mode”. With strict mode, you can not, for example, use undeclared variables.

    Examples of using “use strict”:
    Strict mode for functions: Likewise, to invoke strict mode for a function, put the exact statement “use strict”; (or ‘use strict’;) in the function’s body before any other statements.

    1) strict mode in functions

      function strict() { // Function-level strict mode syntax 'use strict'; function nested() { return 'And so am I!'; } return "Hi! I'm a strict mode function! " + nested(); } function notStrict() { return "I'm not strict."; } console.log(strict(), notStrict()); 

    2) whole-script strict mode

     'use strict'; var v = "Hi! I'm a strict mode script!"; console.log(v); 

    3) Assignment to a non-writable global

     'use strict'; // Assignment to a non-writable global var undefined = 5; // throws a TypeError var Infinity = 5; // throws a TypeError // Assignment to a non-writable property var obj1 = {}; Object.defineProperty(obj1, 'x', { value: 42, writable: false }); obj1.x = 9; // throws a TypeError // Assignment to a getter-only property var obj2 = { get x() { return 17; } }; obj2.x = 5; // throws a TypeError // Assignment to a new property on a non-extensible object. var fixed = {}; Object.preventExtensions(fixed); fixed.newProp = 'ohai'; // throws a TypeError 

    You can read more on MDN .

    Note that use strict was introduced in EcmaScript 5 and was kept since then.

    Below are the conditions to trigger strict mode in ES6 and ES7 :

    • Global code is strict mode code if it begins with a Directive Prologue that contains a Use Strict Directive (see 14.1.1).
    • Module code is always strict mode code.
    • All parts of a ClassDeclaration or a ClassExpression are strict mode code.
    • Eval code is strict mode code if it begins with a Directive Prologue that contains a Use Strict Directive or if the call to eval is a direct eval (see 12.3.4.1) that is contained in strict mode code.
    • Function code is strict mode code if the associated FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, MethodDefinition, or ArrowFunction is contained in strict mode code or if the code that produces the value of the function’s [[ECMAScriptCode]] internal slot begins with a Directive Prologue that contains a Use Strict Directive.
    • Function code that is supplied as the arguments to the built-in Function and Generator constructors is strict mode code if the last argument is a String that when processed is a FunctionBody that begins with a Directive Prologue that contains a Use Strict Directive.

    use strict is a way to make your code safer, cause you can’t use dangerous features which can work not as you expect.And as was writed before it makes code more strict.

    “use strict”; is the ECMA effort to make JavaScript a little bit more robust. It brings in JS an attempt to make it at least a little “strict” (other languages implement strict rules since the 90s). It actually “forces” JavaScript developers to follow some sort of coding best practices. Still, JavaScript is very fragile. There is no such thing as typed variables, typed methods, etc. I strongly recommend JavaScript developers to learn a more robust language such as Java or ActionScript3, and implement the same best practices in your JavaScript code, it will work better and be easier to debug.

    Small example to compare:

    Non-strict mode:

     for (i of [1,2,3]) console.log(i) // output: // 1 // 2 // 3 

    Strict mode:

     'use strict'; for (i of [1,2,3]) console.log(i) // output: // Uncaught ReferenceError: i is not defined 

    The main reasons why developers should use "use strict" are:

    1. Prevents accidental declaration of global variables.Using "use strict()" will make sure that variables are declared with var before use. Per esempio:

       function useStrictDemo(){ 'use strict'; //works fine var a = 'No Problem'; //does not work fine and throws error k = "problem" //even this will throw error someObject = {'problem': 'lot of problem'}; } 
    2. NB: The "use strict" directive is only recognized at the beginning of a script or a function.
    3. The string "arguments" cannot be used as a variable:

       "use strict"; var arguments = 3.14; // This will cause an error 
    4. Will restrict uses of keywords as variables. Trying to use them will throw errors.

    In short will make your code less error prone and in turn will make you write good code.

    To read more about it you can refer here .

    Use Strict is used to show common and repeated errors so that it is handled differently , and changes the way java script runs , such changes are :

    • Prevents accidental globals

    • No duplicates

    • Eliminates with

    • Eliminates this coercion

    • Safer eval()

    • Errors for immutables

    you can also read this article for the details

    Normally java script does not follow strict rules hence increasing chances of errors. After using "use strict" , the java script code should follow strict set of rules as like in other programming languages such as use of terminators, declaration before initialization etc.

    If "use strict" is used then the code should be written by following a strict set of rules hence decreasing the chances of errors and ambiguities.

    JavaScript “strict” mode introduces in ECMAScript 5.

      (function() { "use strict"; your code... })(); 

    writing “use strict”; at the very top of your JS file turns on strict syntax checking. It does the following tasks for us :

    (i) shows an error if you try to assign to an undeclared variable

    (ii) stops you from overwriting key JS system libraries

    (ii) forbids some unsafe or error-prone language features

    “use strict” also works inside of individual functions. It is always a better practice to include “use strict in your code.

    Browser Compatibility Issue: The “use” directives are meant to be backwards-compatible. Browsers that donot support them will just see a String literal that isn’t referenced further. So, they will pass over it and move on.