perché i globals sono pessimi in javascript [duplicato]

Per alcuni motivi:

• Spesso ti costringe a scegliere nomi più lunghi, dove uno più corto sarebbe più chiaro e conciso in un ambito limitato. Ad esempio, filter contro MyModuleNameFilter .
• Il processo di "assumersi la responsabilità di assicurarsi di avere nomi molto buoni e che non si sovrapporranno mai" diventa sempre più difficile quanto più grande è la base di codice (e quanto più si ottiene per quella materia).
• Non sei in grado di condividere il codice con nessun altro che si iscrive alla stessa filosofia.

Poiché le variabili globali hanno un ambito globale, sono visibili e modificabili da qualsiasi cosa venga eseguita sulla pagina. Ciò introduce un accoppiamento implicito tra tutto il codice in esecuzione sulla pagina; tutto potrebbe interagire con tutto.

Ciò è contrario al concetto di incapsulamento. Se il tuo codice e le variabili sono di ambito locale, è più facile ragionare su cosa; solo quelle parti del codice che possono accedere alla variabile potrebbero averlo cambiato.

Quando si tratta di variabili collegate all'oggetto della finestra, non si sa mai dove sono state o chi le ha toccate.

"Mi assumerò la responsabilità di assicurarmi che ...".

Molti bambini inaspettati arrivano in questo modo.

Ma sul serio:

• mantenere i nomi univoci con una base di codice in crescita che potrebbe includere altre librerie è un processo difficile e rischioso che alla fine è destinato a fallire.
• il tuo codice personale inizierà a essere molto difficile da leggere e seguire quando imposti e leggi queste variabili in luoghi diversi. Quando si tratta di una determinata sezione di codice, potresti non essere sicuro del valore della variabile e questo può essere un problema.
• la denominazione delle variabili dovrebbe essere basata su un buon nome per il metodo, non su quali nomi hai già
• i nomi comuni dovrebbero essere ripetibili. dovrebbe essere ok per avere nomi come "filtro", "crea", "nuovo", "indice", "ricerca", ecc. In più punti. Senza namespace di qualche tipo è possibile avere solo queste funzioni una volta.

"Non inserire mai variabili in ambito globale" è una best practice perché rende le variabili fragili. Una tipica pagina web o in particolare una tipica applicazione web è probabile che contenga molti script diversi da più fonti, e con la stessa attenzione con cui si possono tracciare le proprie variabili globali, tutti coloro a cui si fa riferimento con gli script potrebbero non giocare.

Pensalo come un vaccino. Se tutti avessero un vaccino, non ci sarebbero minacce e se tu solo avessi un vaccino non ci sarebbe nessuna minaccia, ma nel frattempo tutti gli altri stanno cercando di farsi vaccinare, quindi potresti probabilmente farla franca senza essere vaccinati perché nessun altro è tuo minaccia, ma questo non funziona esattamente con l'ecosistema di scripting in cui stai lavorando.

C'è una certa latitudine nell'usare i globali se si usa lo spazio dei nomi. La radice del tuo spazio dei nomi è globale, ma ti è consentita solo la variabile radice dello spazio dei nomi. Questo è un compromesso che di solito la comunità di Javascript va bene, in particolare se è limitata alla tua applicazione.

Uno spazio dei nomi potrebbe essere simile a questo:

window.MyNamespace = {
    ClassA: function() { },
    NestedNamespace1: {
        ClassB: function() { }
    }
};

Questo pone ClassA e ClassB nell'annidamento dello spazio dei nomi MyNamespace:

(function() {
    var myClassAInstance = new MyNamespace.ClassA();
    var myClassBInstance = new MyNamesapce.NestedNamespace1.ClassB();
})();

Puoi anche crearlo usando funzioni di namespace come quella che ho creato [ qui ], che spiega anche come puoi sfruttare la semplicità del namespace.

In generale, tuttavia, la raccomandazione è di usare le variabili di chiusura ovunque. Gli spazi dei nomi sono minimi, ma scoraggiati a causa dei vantaggi delle variabili di chiusura. Una variabile di chiusura è una variabile dichiarata nell'esecuzione di una funzione. Tutti i file di script che scrivi devono essere contenuti in una funzione.

(function() { // IIFE (immediately-invoked function expression)

   var myClosureVariable = 3;
   $('#myDomElement').on('click', function() {
       console.log(myClosureVariable); // outputs 3
   });

})();
console.log(myClosureVariable); // outputs undefined

Consideriamo alcuni casi d'uso diversi:

1. Hai una variabile rilevante solo per la durata di una chiamata di funzione o all'interno di una chiusura specifica. Anche se l'uso di un global potrebbe non diventare un problema, non ti dà alcun vantaggio. Rendendolo locale è la scelta facile e sicura.

2. Stai scrivendo una libreria, il tuo codice sarà usato insieme a un codice di cui non hai il controllo. La portata globale non è tua da scherzare. L'unico motivo legittimo per utilizzare l'ambito globale è quello di esporre le funzioni della libreria pubblica. Questi casi devono ovviamente essere documentati in modo che l'utente della biblioteca possa evitare conflitti di nome.

3. Stai scrivendo il tuo progetto e hai una variabile con una durata oltre le tue funzioni. Potresti fare un numero qualsiasi di cose per evitare di renderlo globale, ma questo tende a rendere il tuo codice più complicato, senza alcun reale vantaggio da mostrare per esso. Basta renderlo globale, è la soluzione semplice a un semplice problema. La dichiarazione esplicita nella sezione della dichiarazione globale ne documenterà l'esistenza.

4. Fai parte di un team e hai un ragionevole bisogno di un globale. Questo va da qualche parte tra il caso 2 e 3. Se la variabile deve essere solo globale per il tuo modulo, allora fare una chiusura per esso potrebbe essere il compromesso migliore. Se trascende ciò che è possibile con la tua chiusura, un globale può ancora essere la scelta migliore. Ricordati di documentarlo in qualsiasi modo sia consueto per il progetto.

I Globali vanno bene se usati in maniera prudente. La parte difficile del dibattito è che non puoi ignorare il contesto più ampio in cui è scritto il codice.