Attualmente sto convalidando il mio JavaScript su JSLint e sto facendo progressi, mi sta aiutando a scrivere un JavaScript migliore, in particolare lavorando con la libreria Jquery.

Ora mi sono imbattuto in JSHint , un fork di JSLint .
Quindi mi chiedo per le applicazioni web, che sono state guidate molto da JavaScript, che è lo strumento di validazione migliore o più applicabile contro cui lavorare:

• JSLint o JSHint?

Voglio decidere ora su un meccanismo di validazione e andare avanti, usarlo per la validazione lato client.

E la differenza tra jshint e jslint? Si prega di spiegare in un singolo esempio JavaScript.

link:

1. jshint - http://www.jshint.com/

2. jslint - http://jslint.com/

[EDIT]
Questa risposta è stata modificata. Lascio la risposta originale qui sotto per il contesto (altrimenti i commenti non avrebbero senso).

Quando questa domanda era stata inizialmente posta, JSLint era il principale strumento di linting per JavaScript. JSHint era un nuovo fork di JSLint, ma non si era ancora discostato molto dall'originale.

Da allora, JSLint è rimasto praticamente statico, mentre JSHint è cambiato molto: ha eliminato molte delle regole più antagoniste di JSLint, ha aggiunto un sacco di nuove regole ed è generalmente diventato più flessibile. Inoltre, è ora disponibile un altro strumento ESLint, che è ancora più flessibile e ha più opzioni per le regole.

Nella mia risposta originale, ho detto che non dovresti forzarti a rispettare le regole di JSLint; fintanto che hai capito il motivo per cui stava lanciando un avviso, puoi decidere da solo se modificare il codice per risolvere l'avviso o meno.

Con il set di regole ultra-rigoroso di JSLint del 2011, questo è stato un consiglio ragionevole: ho visto pochissimi set di codici JavaScript in grado di superare un test JSLint. Tuttavia, con le regole più pragmatiche disponibili negli strumenti JSHint ed ESLint di oggi, è una proposta molto più realistica cercare di far passare il codice attraverso di essi con zero avvisi.

Occasionalmente ci possono essere casi in cui una linter si lamenta di qualcosa che hai fatto intenzionalmente - per esempio, sai che dovresti sempre usare, ===ma solo questa volta hai una buona ragione per usarlo ==. Ma anche in questo caso, con ESLint hai la possibilità di specificare eslint-disableintorno alla riga in questione in modo da poter avere ancora un test di sfilacciatura senza avvertimenti, con il resto del codice che obbedisce alla regola. (semplicemente non fare questo genere di cose troppo spesso!)

[SEGUE LA RISPOSTA ORIGINALE]

Usa sicuramente JSLint. Ma non rimanere impigliato nei risultati e nel sistemare tutto ciò di cui ti avverte. Ti aiuterà a migliorare il tuo codice e ti aiuterà a trovare potenziali bug, ma non tutto ciò di cui si lamenta JSLint si rivela un vero problema, quindi non pensare di dover completare il processo con zero avvisi.

Praticamente qualsiasi codice Javascript con lunghezza o complessità significative produrrà avvisi in JSLint, non importa quanto sia ben scritto. Se non mi credi, prova ad eseguire alcune librerie popolari come JQuery.

Alcuni avvisi JSLint sono più preziosi di altri: scopri quali a cui prestare attenzione e quali sono meno importanti. Ogni avviso dovrebbe essere considerato, ma non sentirti obbligato a correggere il tuo codice per cancellare qualsiasi dato avviso; va benissimo guardare il codice e decidere che ne sei contento; ci sono momenti in cui le cose che non piacciono a JSlint sono in realtà la cosa giusta da fare.

tl; dr asporto :

Se stai cercando uno standard molto elevato per te o il tuo team, JSLint. Ma non è necessariamente lo standard, solo uno standard, alcuni dei quali ci vengono dogmaticamente da un dio javascript di nome Doug Crockford. Se vuoi essere un po 'più flessibile, o avere dei vecchi professionisti nella tua squadra che non acquistano le opinioni di JSLint o che vanno avanti e indietro tra JS e altre lingue della famiglia C su base regolare, prova JSHint.

versione lunga :

Il ragionamento dietro la forcella spiega abbastanza bene perché esiste JSHint:

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to -jshint /

Quindi immagino che l'idea sia "guidata dalla comunità" piuttosto che da quella di Crockford. In pratica, JSHint è generalmente un po 'più indulgente (o almeno configurabile o agnostico) su alcune "opinioni" stilistiche e minori sintattiche su cui JSLint è un pignolo.

Ad esempio, se ritieni che sia la A che la B in basso vadano bene o se desideri scrivere un codice con uno o più degli aspetti di A che non sono disponibili in B, JSHint fa per te. Se pensi che B sia l'unica opzione corretta ... JSLint. Sono sicuro che ci sono altre differenze, ma questo ne evidenzia alcune.

A) Passa JSHint fuori dalla scatola - non riesce JSLint

(function() {
  "use strict";
  var x=0, y=2;
  function add(val1, val2){
    return val1 + val2;
  }
  var z;
  for (var i=0; i<2; i++){
    z = add(y, x+i);
  }
})();

B) Passa sia JSHint che JSLint

(function () {
    "use strict";
    var x = 0, y = 2, i, z;
    function add(val1, val2) {
       return val1 + val2;
    }
    for (i = 0; i < 2; i += 1) {
        z = add(y, x + i);
    }
}());

Personalmente trovo che il codice JSLint sia molto bello da vedere e le uniche caratteristiche difficili di cui non sono d'accordo sono l' odio per più di una dichiarazione var in una funzione e delle var i = 0dichiarazioni for-loop , e alcune delle applicazioni degli spazi bianchi per le dichiarazioni delle funzioni .

Alcune delle cose degli spazi bianchi che JSLint applica, trovo che non siano necessariamente cattive, ma non sincronizzate con alcune convenzioni degli spazi bianchi piuttosto standard per altre lingue della famiglia (C, Java, Python, ecc ...), che sono spesso seguiti come convenzioni anche in Javascript. Dal momento che scrivo in varie lingue durante il giorno e lavoro con i membri del team a cui non piace lo spazio bianco in stile Lint nel nostro codice, trovo che JSHint sia un buon equilibrio. Cattura roba che è un bug legittimo o una forma davvero cattiva, ma non mi abbaia come JSLint (a volte, in modi che non posso disabilitare) per le opinioni stilistiche o le chiacchiere sintattiche che non mi interessano.

Molte buone librerie non sono Lint'able, il che per me dimostra che c'è del vero nell'idea che parte di JSLint riguardi semplicemente la versione 1 di "buon codice" (che è, in effetti, un buon codice). Ma ancora una volta, le stesse librerie (o altre buone) probabilmente non sono neanche Hint'able, quindi, touché.

Esiste un altro "player" maturo e sviluppato attivamente sul fronte del javascript ESLint:

ESLint è uno strumento per identificare e riferire sui modelli trovati nel codice ECMAScript / JavaScript. In molti modi, è simile a JSLint e JSHint con alcune eccezioni:

• ESLint utilizza Esprima per l'analisi JavaScript.
• ESLint utilizza un AST per valutare i modelli nel codice.
• ESLint è completamente collegabile, ogni singola regola è un plug-in e puoi aggiungerne altri in fase di esecuzione.

Ciò che conta davvero qui è che è estendibile tramite plugin / regole personalizzati . Esistono già più plugin scritti per scopi diversi. Tra gli altri , ci sono:

• eslint-plugin-angular (applica alcune delle linee guida della Guida angolare di stile di John Papa )
• eslint-plugin-gelsomino
• eslint-plugin-spina dorsale

E, naturalmente, puoi usare il tuo strumento di creazione preferito per eseguire ESLint:

• grugnito-eslint
• gulp-eslint

Ho avuto la stessa domanda un paio di settimane fa e stavo valutando sia JSLint che JSHint.

Contrariamente alle risposte a questa domanda, la mia conclusione non è stata:

Usa sicuramente JSLint.

O:

Se stai cercando uno standard molto elevato per te o il tuo team, JSLint.

Come puoi configurare quasi le stesse regole in JSHint di JSLint. Quindi direi che non c'è molta differenza nelle regole che potresti raggiungere.

Quindi i motivi per scegliere uno sopra l'altro sono più politici che tecnici.

Abbiamo finalmente deciso di utilizzare JSHint per i seguenti motivi:

• Sembra essere più configurabile di JSLint.
• Sembra decisamente più guidato dalla comunità piuttosto che da uno spettacolo per uomini (non importa quanto sia bello The Man ).
• JSHint ha abbinato il nostro stile di codice OOTB meglio di JSLint.

Farei un terzo suggerimento, Google Closure Compiler (e anche Closure Linter ). Puoi provarlo online qui .

Il compilatore di chiusura è uno strumento per eseguire download e l'esecuzione di JavaScript più velocemente. È un vero compilatore per JavaScript. Invece di compilare da una lingua di origine al codice macchina, compila da JavaScript a JavaScript migliore. Analizza il tuo JavaScript, lo analizza, rimuove il codice morto e riscrive e minimizza ciò che rimane. Controlla anche la sintassi, i riferimenti alle variabili e i tipi e avverte di insidie ​​JavaScript comuni.

Premessa: beh, si è intensificato rapidamente. Ma ho deciso di farcela. Possa questa risposta essere utile a te e agli altri lettori.

Suggerimenti sul codice

Mentre JSLint e JSHint sono buoni strumenti da usare, nel corso degli anni ho imparato ad apprezzare ciò che il mio amico @ugly_syntax chiama:

spazio di design più piccolo .

Questo è un principio generale, molto simile a un "monaco zen", che limita le scelte che si devono fare, si può essere più produttivi e creativi.

Pertanto, il mio attuale stile di codice JS preferito a zero config:

StandardJS .

AGGIORNAMENTO :

Il flusso è migliorato molto. Con esso, puoi aggiungere tipi al tuo JS con ti aiuterà a prevenire molti bug. Ma può anche stare lontano dalla tua strada, ad esempio quando si interfaccia JS non tipizzato. Provaci!

Avvio rapido / TL; DR

Aggiungi standardcome dipendenza al tuo progetto

npm install --save standard

Quindi package.json, aggiungi il seguente script di prova:

"scripts": {
    "test": "node_modules/.bin/standard && echo put further tests here"
},

Per output più snazzi durante lo sviluppo npm install --global snazzyed eseguirlo invece di npm test.

Nota: verifica del tipo rispetto all'euristica

Amico mio quando menziono lo spazio di design riferito a Elm e ti incoraggio a provare quella lingua.

Perché? JS è infatti ispirato a LISP, che è una classe speciale di lingue, che sembra essere tipizzata . Linguaggi come Elm o Purescript sono linguaggi di programmazione funzionali digitati .

Digita restringi la tua libertà affinché il compilatore sia in grado di controllarti e guidarti quando finisci per violare la lingua o le regole del tuo programma; indipendentemente dalle dimensioni (LOC) del programma.

Recentemente abbiamo avuto un collega junior implementare due volte un'interfaccia reattiva: una volta a Elm, una volta a React; dai un'occhiata per avere un'idea di cosa sto parlando.

Confronta Main.elm(digitato) ⇔ index.js(non tipizzato, nessun test)

(ps. nota che il codice React non è idiomatico e potrebbe essere migliorato)

Un'ultima osservazione,

la realtà è che JS non è tipizzato. Chi sono io per suggerirti una programmazione tipizzata ?

Vedi, con JS siamo in un dominio diverso: liberati dai tipi, possiamo facilmente esprimere cose che sono difficili o impossibili da dare un tipo adeguato (che può certamente essere un vantaggio).

Ma senza i tipi c'è poco da tenere sotto controllo i nostri programmi, quindi siamo costretti a introdurre test e (in misura minore) stili di codice.

Ti consiglio di dare un'occhiata a LISP (ad es. ClojureScript ) come fonte di ispirazione e di investire nel test dei tuoi codici. Leggi Il modo del sottoinsieme per avere un'idea.

Pace.

Bene, invece di eseguire impostazioni manuali per i filacci, possiamo includere tutte le impostazioni lanugine nella parte superiore del nostro file JS stesso, ad es

Dichiara tutte le var globali in quel file come:

/*global require,dojo,dojoConfig,alert */

Dichiara tutte le impostazioni di lanugine come:

/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */

Spero che questo ti possa aiutare :)

C'è anche un'altra alternativa attivamente sviluppata - JSCS - Stile codice JavaScript :

JSCS è una linter in stile codice per applicare a livello di codice la tua guida di stile. Puoi configurare JSCS per il tuo progetto in dettaglio utilizzando oltre 150 regole di convalida, inclusi i preset di guide di stile popolari come jQuery, Airbnb, Google e altro.

Viene fornito con più preset tra cui è possibile scegliere semplicemente specificando presetnel .jscsrcfile di configurazione e personalizzandolo - sovrascrivendo, abilitando o disabilitando qualsiasi regola:

{
    "preset": "jquery",
    "requireCurlyBraces": null
}

Ci sono anche plugin ed estensioni creati per editor popolari.

Vedi anche:

• Codice perfetto, zero sforzi