Ar trebui să folosesc JSLint sau JSHint pentru validarea JavaScript?

În prezent, îmi validez JavaScript-ul folosind JSLint și fac progrese; acesta mă ajută să scriu JavaScript mai bun - în special în lucrul cu biblioteca jQuery.

Am dat acum peste JSHint, un branch al JSLint.
Așadar, mă întreb pentru aplicațiile web, care sunt foarte mult conduse de JavaScript, care este uneltele de validare mai bună sau mai aplicabilă pentru a fi utilizată:

  • JSLint sau JSHint?

Vreau să decid acum asupra unui mecanism de validare și, de acum înainte, să folosesc acesta pentru validarea pe partea clientului.

Și diferența dintre jshint și jslint? Vă rog să explicați într-un singur exemplu de JavaScript.

Legături :

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

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

Răspuns #1

Rezumat

Folosește JSLint dacă cauți un standard foarte ridicat pentru tine sau echipa ta, dar ține cont că nu este neapărat standardul, ci doar un standard, o parte dintre acestea venind la noi dogmatic de la Doug Crockford.

Dacă vrei să fii puțin mai flexibil sau ai niște profesioniști mai vechi în echipa ta care nu sunt de acord cu opiniile JSLint sau trec regulat între JavaScript și alte limbaje din familia C, încearcă JSHint.

Versiune completă

Două articole cu raționamentul din spatele bifurcației explică de ce există JSHint:

  1. JSHint: Un Fork Condus de Comunitate al JSLint

  2. De ce am făcut un fork la JSLint pentru a crea JSHint

Ideea din spatele JSLint este că este condus de comunitate mai degrabă decât de Crockford. JSHint este în general mai permisiv (sau cel puțin configurabil sau agnostic) în privința câtorva opinii stilistice și sintactice minore pentru care JSLint este mai strict.

De exemplu, dacă crezi că atât 1. cât și 2. de mai jos sunt acceptabile, sau dacă vrei să scrii cod folosind unul sau mai multe dintre aspectele lui 1. care nu sunt disponibile în 2., JSHint este pentru tine. Dacă crezi că 2. este singura opțiune corectă, folosește JSLint. Sunt sigur că există și alte diferențe, dar acestea evidențiază câteva.

  1. Trece JSHint din start - nu trece 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);
  }
})();

  2. Trece atât JSHint, cât și 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);
    }
}());

Consider că codul JSLint este mai atrăgător vizual. Singurele aspecte cu care nu sunt de acord sunt ura sa față de mai mult de o declarație var într-o funcție și față de declarațiile var i=0 în buclele for, precum și unele dintre impunerile de spațiu alb pentru declarațiile de funcții.

Unele dintre aspectele legate de spațiile albe pe care JSLint le impune nu sunt neapărat rele, ci doar nu sunt în sincron cu câteva convenții destul de standard pentru spațiile albe din alte limbaje din aceeași familie (C, Java, Python etc.), deseori urmate ca convenții și în Javascript. Deoarece scriu în diferite dintre aceste limbaje pe parcursul zilei și lucrez cu membri ai echipei care nu plac spațiile albe în stil Lint în codul nostru, consider că JSHint este un echilibru bun. Detectează erori legitime și cod foarte prost format, dar nu latră la mine așa cum o face JSLint (uneori, în moduri pe care nu le pot dezactiva) pentru opiniile stilistice sau pentru subtilitățile sintactice care nu mă interesează.

Multe biblioteci bune nu pot fi verificate cu Lint, ceea ce, pentru mine, demonstrează că există ceva adevăr în ideea că o parte din JSLint este doar despre promovarea unei versiuni a „codului bun” (care, într-adevăr, este cod bun). Dar, pe de altă parte, aceleași biblioteci (sau altele bune) probabil că nu pot fi verificate nici cu Hint, deci, touché.

Răspunsul #2

[EDITARE]
Acest răspuns a fost editat. Las răspunsul original mai jos pentru context (altfel comentariile nu ar avea sens).

Când această întrebare a fost pusă inițial, JSLint era principalul instrument de linting pentru JavaScript. JSHint era un nou fork al JSLint, dar nu se diferențiase încă mult de original.

De atunci, JSLint a rămas cam la fel, în timp ce JSHint s-a schimbat foarte mult - a eliminat multe dintre regulile mai antagonice ale JSLint, a adăugat o mulțime de reguli noi și, în general, a devenit mai flexibil. De asemenea, un alt instrument, ESLint, este acum disponibil, fiind și mai flexibil și având mai multe opțiuni de reguli.

În răspunsul meu original, am spus că nu ar trebui să te forțezi să respecți regulile JSLint; atâta timp cât ai înțeles de ce a generat un avertisment, puteai să îți faci singur o judecată despre dacă să modifici codul pentru a rezolva avertismentul sau nu.

Cu setul ultra-strict de reguli al JSLint din 2011, acesta era un sfat rezonabil -- am văzut foarte puține seturi de cod JavaScript care să treacă un test JSLint. Totuși, cu regulile mai pragmatice disponibile în instrumentele JSHint și ESLint de astăzi, este o propunere mult mai realistă să încerci să faci codul tău să treacă prin ele fără nicio avertizare.

Pot exista totuși cazuri ocazionale în care un linter se va plânge de ceva ce ai făcut intenționat -- de exemplu, știi că ar trebui să folosești întotdeauna ===, dar doar de această dată ai un motiv întemeiat să folosești ==. Dar chiar și atunci, cu ESLint ai opțiunea de a specifica eslint-disable în jurul liniei în cauză, astfel încât să poți avea totuși un test lint trecut fără niciun avertisment, restul codului tău respectând regula. (doar să nu faci asta prea des!)

[URMĂRĂRĂ RĂSPUNS ORIGINAL]

Folosește JSLint cu siguranță. Dar nu te lăsa prins de rezultate și de corectarea fiecărui aspect despre care avertizează. Te va ajuta să-ți îmbunătățești codul și îți va ajuta să găsești eventuale erori, dar nu tot ce reclamă JSLint se dovedește a fi o problemă reală, așa că nu simți că trebuie să finalizezi procesul fără nicio avertizare.

Aproape orice cod Javascript cu orice lungime sau complexitate semnificativă va produce avertismente în JSLint, indiferent cât de bine este scris. Dacă nu mă credeți, încercați să rulați prin el câteva librării populare precum JQuery.

Unele avertismente JSLint sunt mai valoroase decât altele: învață care trebuie urmărite și care sunt mai puțin importante. Fiecare avertisment ar trebui luat în considerare, dar nu te simți obligat să îți modifici codul pentru a elimina un anumit avertisment; este perfect în regulă să te uiți la cod și să decizi că ești mulțumit de el; există momente când lucrurile pe care JSLint nu le agreează sunt de fapt lucrurile corecte de făcut.

Răspunsul #3

Există un alt jucător matur și activ dezvoltat pe frontul verificării codului JavaScript - ESLint:

ESLint este un instrument pentru identificarea și raportarea modelelor găsite în codul ECMAScript/JavaScript. În multe privințe, este similar cu JSLint și JSHint, cu câteva excepții:

  • ESLint folosește Esprima pentru analizarea JavaScript-ului.
  • ESLint folosește un AST pentru a evalua tiparele din cod.
  • ESLint este complet modular, fiecare regulă este un plugin și poți adăuga mai multe în timpul rulării.

Ceea ce contează cu adevărat aici este că este extensibil prin pluginuri/reguli personalizate. Există deja mai multe pluginuri scrise pentru diferite scopuri. Printre altele, există:

  • eslint-plugin-angular (aplică unele dintre ghidurile din Angular Style Guide al lui John Papa)
  • eslint-plugin-jasmine
  • eslint-plugin-backbone

Și, bineînțeles, poți folosi instrumentul de construire preferat pentru a rula ESLint:

  • grunt-eslint
  • gulp-eslint

Răspunsul #4

Am avut aceeași întrebare acum câteva săptămâni și evaluam atât JSLint, cât și JSHint.

Contrar răspunsurilor din această întrebare, concluzia mea nu a fost:

Cu orice mijloace folosește JSLint.

Aur :

Dacă cauți un standard foarte ridicat pentru tine sau pentru echipa ta, JSLint.

Așa cum puteți configura aproape aceleași reguli în JSHint ca și în JSLint. Deci aș susține că nu există prea multe diferențe în regulile pe care le-ați putea obține.

Deci motivele pentru a alege unul în locul altuia sunt mai mult politice decât tehnice.

Am decis în cele din urmă să folosim JSHint din următoarele motive:

  • Se pare că este mai configurabil decât JSLint.
  • Arată cu siguranță mai mult orientat spre comunitate decât ca un spectacol de unul singur (indiferent cât de grozav este Bărbatul).
  • JSHint s-a potrivit cu stilul nostru de cod OOTB mai bine decât JSLint.

Răspunsul #5

Aș face o a treia sugestie, Google Closure Compiler (și de asemenea Closure Linter). Poți să-l încerci online aici.

Closure Compiler este un instrument pentru a face ca descărcarea și rularea JavaScript să fie mai rapidă. Este un adevărat compilator pentru JavaScript. În loc să compileze dintr-un limbaj sursă în cod mașină, compilează din JavaScript în JavaScript mai bun. Analizează JavaScript-ul tău, îl verifică, elimină codul nefolosit și rescrie și minimizează ceea ce rămâne. De asemenea, verifică sintaxa, referințele variabilelor și tipurile, și avertizează despre capcanele comune din JavaScript.

Răspuns #6

Cuvânt înainte: Ei bine, lucrurile au escaladat rapid. Dar am decis să duc totul la bun sfârșit. Fie ca acest răspuns să vă fie de folos dumneavoastră și altor cititori.

Sugestii de cod

Deși JSLint și JSHint sunt unelte bune de folosit, de-a lungul anilor am ajuns să apreciez ceea ce prietenul meu @ugly_syntax numește:

spațiu de proiectare mai mic.

Acesta este un principiu general, asemănător cu un „călugăr zen”, limitând alegerile pe care trebuie să le faci, poți fi mai productiv și creativ.

Prin urmare, stilul meu actual preferat de cod JS fără configurare:

StandardJS.

ACTUALIZARE:

Flow s-a îmbunătățit mult. Cu el, poți adăuga tipuri în JS-ul tău, ceea ce te va ajuta să previi multe bug-uri. Dar poate și să stea deoparte, de exemplu atunci când interacționezi cu JS-necodat. Încearcă-l!

Pornire rapidă/TL;DR

Adaugă standard ca dependență proiectului tău

npm install --save standard

Apoi, în package.json, adaugă următorul script de testare:

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

Pentru rezultate mai elegante în timpul dezvoltării, npm install --global snazzy și rulează-l în loc de npm test.

Notă: Verificarea tipului versus euristici

Prietenul meu, atunci când a menționat spațiul de design, s-a referit la Elm și te încurajez să încerci acel limbaj.

De ce? JS este de fapt inspirat de LISP, care este o clasă specială de limbaje, care întâmplător este neatribuit. Limbaje precum Elm sau Purescript sunt limbaje de programare funcționale atribuite.

Tipul restricționează libertatea ta pentru ca compilatorul să poată verifica și ghida atunci când încalci regulile limbajului sau ale propriului tău program; indiferent de dimensiunea (LOC) programului tău.

Recent, am avut un coleg junior care a implementat o interfață reactivă de două ori: o dată în Elm, o dată în React; aruncă o privire pentru a avea o idee despre ce vorbesc.

Comparați Main.elm (tipizat) ⇔ index.js (netipizat, fără teste)

(ps. rețineți că codul React nu este idiomatic și ar putea fi îmbunătățit)

O ultimă observație,

realitatea este că JS nu are tipuri. Cine sunt eu să vă sugerez programare tipizată?

Vezi, cu JS suntem într-un domeniu diferit: eliberați de tipuri, putem exprima cu ușurință lucruri care sunt greu sau imposibil de atribuit unui tip corespunzător (ceea ce poate fi cu siguranță un avantaj).

Dar fără tipuri există puțin care să mențină programele noastre sub control, așa că suntem forțați să introducem teste și (într-o măsură mai mică) stiluri de cod.

Îți recomand să te uiți la LISP (de exemplu ClojureScript) pentru inspirație și să investești în testarea codurilor tale. Citește The way of the substack pentru a-ți face o idee.

Pace.