Dollar Sign Blues: Javascript e PHP

Question

Dollar Sign Blues: Javascript e PHP

#1 da (11 voti)

18

Sono cresciuto programmando C ++ e Java dove tutto era sicuro e bello. I compilatori si sono assicurati di tenermi sotto controllo se mai mi fossi allontanato. Certo, tutti hanno fatto un po 'di Perl al college, ma non l'ho fatto. I bambini in questi giorni sono tutti di PHP sul backend e Javascript sul fronte. Nel cercare di essere alla moda, faccio lo stesso (per lo sviluppo web). Il problema che continuo a correre è che accidentalmente aggiungo un segno di dollaro ($) davanti a variabili regolari in Javascript e ovviamente nessuno dice nulla perché questa è la sintassi legale usata spesso per gli oggetti jQuery.

Esistono strumenti di debug o trucchi per il trucco per catturare questa confusione nel segno del dollaro? Fai spesso lo stesso errore e come lo gestisci 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 dirmelo per dispetto.

Se pensi che questa domanda sia ridicola, penso che tu abbia ragione. Ma viviamo in un mondo in cui una variabile ha un segno di dollaro di fronte ad essa. In un mondo del genere, nulla è ridicolo.

debugging variables javascript syntax php

posta Alan Turing 08.06.2013 - 23:31

fonte

1 risposta

Leggi altre domande sui tag debugging variables javascript syntax php

Qual è lo scopo di questa apparente auto-referenza in C #? Quali sono i problemi che risolvono le nuove funzionalità di python 3? [chiuso]

score 11 · Accepted Answer

Non c'è niente di sbagliato nell'usare $ nelle variabili. Non lo farei apposta 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é non vi sono errori in primo luogo.

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 questi? Sta a te scegliere. Per aiutarti, ecco alcune note:

Stile

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

Molti sviluppatori hanno familiarità con lo stile di Douglas Crockford. Questo stile è spiegato dettagliatamente in JavaScript: The Good Parts , un libro che può essere acquistato da chiunque lavori con JavaScript .

Per quanto riguarda jsHint, non riesco davvero a trovare le convenzioni utilizzate, e il sito web sembra evitarsi di parlare di quell'argomento. Forse mi sono perso qualcosa.

Supporto per IDE

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

Ambiente

Google Closure Linter è 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 severo. jsHint è più permissivo, che non è sempre una buona cosa. Ad esempio, uno dei motivi per fork di jsLint per jsHint è spiegato in un articolo che mostra codice errato che produce 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 è cattivo, perché sembra che JavaScript abbia un ambito di blocco, mentre non lo è. Vedi JavaScript: Le buone parti, p. 102, Appendice A: Awful Parts, Scope. In altre parole, guardando il codice senza conoscere la lingua, ci aspettiamo che name non sia visibile al di fuori del ciclo, mentre rimarrà visibile.

Per quanto riguarda Google Closure Linter, credo che sia da qualche parte nel mezzo tra jsLint e jsHint, ma non ho abbastanza informazioni per supportarlo.

Conclusione

Eviterei jsHint: è troppo permissivo, il che significa che non troverà 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, seguita da migliaia di sviluppatori. Usa entrambi per un po 'di tempo, quindi scegli quello che è più pratico per te.