Dollar Sign Blues: Javascript e PHP

Sono cresciuto programmando C ++ e Java dove tutto era sicuro e bello. I compilatori si sono assicurati di tenermi sotto controllo se mi sono mai smarrito. Certo, tutti hanno fatto un po 'di Perl al college, ma io non ho inspirato. I bambini in questi giorni sono tutti incentrati su PHP sul backend e Javascript sul fronte. Nel tentativo di essere alla moda, faccio lo stesso (per lo sviluppo web). Il problema in cui mi imbatto è l'aggiunta accidentale di un simbolo di dollaro ($) davanti a variabili regolari in Javascript e, naturalmente, nessuno dice nulla perché si tratta della sintassi legale spesso usata per gli oggetti jQuery.

Ci sono strumenti di debug o trucchi di sviluppo per cogliere questa confusione del simbolo del dollaro? Fai spesso lo stesso errore e come lo affronti emotivamente? Gli strumenti di sviluppo di Chrome non sempre vedono che si tratta di un errore Javascript. Uso PhpStorm ed Emacs per lo sviluppo, ma quelli non catturano la mia stupidità, anche se sospetto che Emacs lo faccia ma sceglie di non parlarmene per dispetto.

Se pensi che questa domanda sia ridicola, penso che tu abbia ragione. Ma viviamo in un mondo in cui una variabile ha davanti un simbolo del dollaro. In un mondo simile, nulla è ridicolo.

Non c'è niente di sbagliato nell'uso delle $variabili. Non lo farei di proposito su ogni variabile, ma è comunque una sintassi valida. jQuery è uno degli esempi in cui $viene utilizzato come nome di variabile. Questo è anche il motivo per cui "Gli strumenti di sviluppo di Chrome non sempre vedono che si tratta di un errore Javascript" , perché in primo luogo non c'è errore.

Se hai paura di scrivere codice come:

var demo = function demo() {
    var a = 123;
    ...
    $a = 456; // A new variable is created in global scope.
}

allora devi usare un controllo di stile, come jsLint , jsHint o Google Closure Linter . Quale di quelli? Sta a te fare una scelta. Per aiutarti in questo, ecco alcune note:

Stile

Google Losure Linter segue la Guida di stile JavaScript di Google , nota per essere stata eseguita in modo intelligente. Usare uno stile ben noto per JavaScript o una qualsiasi delle altre sei lingue è una buona idea: quando condividi il tuo codice o assumi un nuovo sviluppatore, è probabile che abbiano già familiarità con questo stile.

Molti sviluppatori hanno familiarità anche con lo stile di Douglas Crockford. Questo stile è spiegato in dettaglio in JavaScript: The Good Parts , un libro che vale la pena acquistare da chiunque lavori con JavaScript.

Per quanto riguarda jsHint, non riesco davvero a trovare le convenzioni utilizzate e il sito Web stesso sembra evitare di parlare di tale argomento. Forse mi sono perso qualcosa.

Supporto da IDE

Sia jsLint che jsHint sono supportati da PhpStorm. Questo è anche il caso di Google Closure Linter.

Ambiente

Google Closure Linter fa parte di una serie di strumenti . Se stai già utilizzando Google Closure Compiler o Google Closure Library , sarebbe preferibile scegliere Closure Linter sopra altri strumenti.

Rigore

jsLint è noto per essere rigoroso. jsHint è più permissivo, il che non è sempre una buona cosa. Ad esempio, uno dei motivi per fork di jsLint per jsHint è spiegato in un articolo che mostra un codice errato che produrrà un errore in jsLint, ma non in jsHint:

/*global jQuery */

// Example taken from jQuery 1.4.2 source
jQuery.extend({
    /* ... */

    isEmptyObject: function( obj ) {
        for ( var name in obj ) {
            return false;
        }
        return true;
    }

    /* ... */
});

Il codice è errato, perché sembra che JavaScript abbia un ambito di blocco, mentre non lo è. Vedi JavaScript: The Good Parts, p. 102, Appendice A: Parti orribili, ambito di applicazione. In altre parole, guardando il codice senza conoscere la lingua, ci aspettiamo namedi non essere visibili al di fuori del ciclo, mentre rimarrà visibile.

Per quanto riguarda Google Closure Linter, credo che si trovi a metà strada tra jsLint e jsHint, ma non ho abbastanza informazioni per supportarlo.

Conclusione

Eviterei jsHint: è troppo permissivo, nel senso che non troverebbe potenziali bug che gli altri linters potrebbero rilevare. La guida di stile utilizzata è difficile da trovare.

Tra jsLint e Google Closure Linter, la scelta non è ovvia. Entrambi sono scritti da esperti, entrambi seguono una guida di stile rigorosa e ben descritta già seguita da migliaia di sviluppatori. Usa entrambi per un po 'di tempo, quindi scegline uno più pratico per te.