Sollte ich JSLINT- oder JSHINT JavaScript -Validierung verwenden? [abgeschlossen

https://stackoverflow.com/questions/6803305

25-10-2019
|

Frage

Ich bestätige derzeit mein JavaScript gegen JSlint und mache Fortschritte. Es hilft mir, bessere JavaScript zu schreiben - insbesondere bei der Arbeit mit der JQuery -Bibliothek.

Ich bin jetzt vorgekommen JSHINT, eine Gabel von JSlint.
Ich wundere mich also nach Webanwendungen, die sehr viel JavaScript sind, was das bessere oder am besten anwendbare Validierungsinstrument ist, gegen das wir arbeiten, gegen:

JSLINT oder JSHINT?

Ich möchte jetzt über einen Validierungsmechanismus entscheiden und vorwärts gehen. Verwenden Sie dies für die Client -Seitenvalidierung.

Und Unterschied zwischen JSHINT und JSINT? Bitte erläutern Sie im Einzel -JavaScript -Beispiel.

Links:

JSHINT- http://www.jshint.com/
JSlint- http://jslint.com/

Lösung

BEARBEITEN
Diese Antwort wurde bearbeitet. Ich verlasse die ursprüngliche Antwort unten für den Kontext (sonst würden die Kommentare keinen Sinn ergeben).

Als diese Frage ursprünglich gestellt wurde, war JSlint das Hauptleistungsinstrument für JavaScript. JSHINT war eine neue Gabel von JSlint, hatte aber noch nicht viel vom Original abgewiesen.

Seitdem ist JSlint ziemlich statisch geblieben, während sich Jsint sehr verändert hat - es hat viele der antagonistischeren Regeln von JSlint weggeworfen, eine ganze Menge neuer Regeln hinzugefügt und ist im Allgemeinen flexibler geworden. Ein weiteres Tool ist jetzt verfügbar, das jetzt noch flexibler ist und mehr Regeloptionen hat.

In meiner ursprünglichen Antwort sagte ich, dass Sie sich nicht zwingen sollten, sich an die Regeln von JSlint zu halten. Solange Sie verstanden haben, warum es eine Warnung geworfen hat, könnten Sie ein Urteil darüber machen, ob Sie den Code ändern möchten, um die Warnung zu beheben oder nicht.

Mit dem Ultra-Strikt-Regeln von JSlint aus dem Jahr 2011 war dies ein vernünftiger Rat-ich habe nur sehr wenige JavaScript-Codesets gesehen, die einen JSLINT-Test bestehen könnten. Angesichts der pragmatischeren Regeln in den heutigen JSHINT- und Eslint -Tools ist es jedoch ein viel realistischeres Angebot, Ihren Code mit null Warnungen durchzuführen.

Es kann immer noch Fälle geben, in denen sich ein Verbrecher über etwas beschwert, das Sie absichtlich getan haben - zum Beispiel wissen Sie, dass Sie immer verwenden sollten === Aber nur dieses eine Mal haben Sie einen guten Grund zu verwenden ==. Aber selbst dann haben Sie mit Eslint die Möglichkeit, festzulegen eslint-disable Um die fragliche Zeile, sodass Sie immer noch einen vorübergehenden Lint -Test ohne Warnungen durchführen können, wobei der Rest Ihres Codes der Regel befolgt. (Mach einfach nicht zu oft so etwas!)

Originalantwort folgt

Verwenden Sie auf jeden Fall JSlint. Aber lassen Sie sich nicht an die Ergebnisse aufhalten und alles beheben, was es warnt, was es warnt. Es wird Ihnen helfen, Ihren Code zu verbessern, und es wird Ihnen helfen, potenzielle Fehler zu finden, aber nicht alles, worüber sich Jslint beschwert, stellt sich als ein echtes Problem heraus. Sie haben also nicht das Gefühl, den Prozess mit Null Warnungen abzuschließen.

So ziemlich jeder JavaScript -Code mit einer erheblichen Länge oder Komplexität führt zu Warnungen in JSlint, egal wie gut es geschrieben ist. Wenn Sie mir nicht glauben, versuchen Sie, einige beliebte Bibliotheken wie JQuery durchzuführen.

Einige JSLINT -Warnungen sind wertvoller als andere: Lernen Sie, auf welche Sie achten müssen und welche weniger wichtig sind. Jede Warnung sollte berücksichtigt werden, fühlen sich jedoch nicht verpflichtet, Ihren Code zu beheben, um eine bestimmte Warnung zu beseitigen. Es ist vollkommen in Ordnung, den Code anzusehen und zu entscheiden, dass Sie damit zufrieden sind. Es gibt Zeiten, in denen Jslint nicht das Richtige sind.

Andere Tipps

tl; Dr. Takeaway:

Wenn Sie nach einem sehr hohen Standard für sich selbst oder das Team suchen, JSlint. Aber es ist nicht unbedingt der Standard, nur ein Standard, von dem einige dogmatisch von einem JavaScript -Gott namens Doug Crockford zu uns kommen. Wenn Sie etwas flexibler sein möchten oder einige alte Profis in Ihrem Team haben, die sich nicht in JSlints Meinungen einkaufen oder zwischen JS und anderen Sprachen der C-Familie regelmäßig hin und her gehen, versuchen Sie es mit JSHINT.

lange Version:

Die Argumentation hinter der Gabel erklärt ziemlich gut, warum JSHINT existiert:

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

Ich denke, die Idee ist, dass es sich eher um "Community-betrieben" als um Crockford-gesteuerte. In der Praktikabilität ist JSHINT in der Regel etwas milde (oder zumindest konfigurierbarer oder agnostischer) in einigen stilistischen und kleinen syntaktischen "Meinungen", auf denen JSINT ein Stickler ist.

Wenn Sie beispielsweise der Meinung sind, dass sowohl A als auch B unten in Ordnung sind oder wenn Sie Code mit einem oder mehreren Aspekten von a schreiben möchten, die in B nicht verfügbar sind, ist JsHint für Sie. Wenn Sie der Meinung sind, dass B die einzig korrekte Option ist ... JSlint. Ich bin sicher, es gibt andere Unterschiede, aber dies zeigt einige.

A) Pässt JSHINT aus der Schachtel - fehlschlägt 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) passt sowohl Jsint als auch JSlint vorbei

(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);
    }
}());

Persönlich finde ich Jslintcode sehr schön anzusehen, und die einzigen schwierigen Merkmale, mit denen ich nicht einverstanden bin Hass auf mehr als eine VaR-Deklaration in einer Funktion und von For-Loop var i = 0 Erklärungen, und einige der Whitespace -Durchsetzungen für Funktionserklärungen.

Ein paar der Whitespace -Dinge, die JSlint erzwingt, bin ich nicht unbedingt schlecht, sondern aus der Synchronisierung mit einigen ziemlich Standard -Whitespace -Konventionen für andere Sprachen in der Familie (C, Java, Python usw.), die oft sind folgte auch als Konventionen in JavaScript. Da ich den ganzen Tag über in verschiedenen dieser Sprachen schreibe und mit Teammitgliedern arbeite, die in unserem Code keine Whitespace-Whitespace mögen, finde ich JSHINT eine gute Balance. Es fängt Dinge auf, die ein legitimer Fehler oder eine wirklich schlechte Form sind, bellt mich aber nicht wie JSlint (manchmal auf eine Weise, die ich nicht deaktivieren kann) für die stilistischen Meinungen oder syntaktischen Nitpicks, die mir egal sind.

Viele gute Bibliotheken sind nicht fusselbar, was für mich zeigt, dass die Idee eine gewisse Wahrheit hat, dass bei einigen von JSlint einfach nur die 1 -Version von "Good Code" (was in der Tat guter Code ist). Aber andererseits sind dieselben Bibliotheken (oder andere gute) wahrscheinlich auch nicht angedeutlich, also Touché.

Es gibt eine andere reif und aktiv entwickelt "Spieler" auf der JavaScript -Linie vorne - ESLint:

Eslint ist ein Instrument zur Identifizierung und Berichterstattung über Muster, die im CODE ECMASSCIPT/JavaScript enthalten sind. In vielerlei Hinsicht ähnelt es JSlint und JSHINT mit wenigen Ausnahmen:

Eslint verwendet Esprima für JavaScript Parsing.

Eslint verwendet ein AST, um Muster im Code zu bewerten.

Eslint ist vollständig steckbar, jede einzelne Regel ist ein Plugin und Sie können zur Laufzeit mehr hinzufügen.

Was hier wirklich wichtig ist, ist, dass es ist Erweiterbar über benutzerdefinierte Plugins/Regeln. Es sind bereits mehrere Plugins für verschiedene Zwecke geschrieben. Unter Andere, es gibt:

Eslint-Plugin-Angular (erzwingt einige der Richtlinien von John Papas Angular Style Guide)
Eslint-Plugin-Jasmin
Eslint-Plugin-Backbone

Und natürlich können Sie Ihr Build -Tool der Wahl zum Ausführen verwenden ESLint:

Ich hatte vor ein paar Wochen die gleiche Frage und bewertete sowohl JSlint als auch JSHINT.

Entgegen den Antworten in dieser Frage war meine Schlussfolgerung nicht:

Verwenden Sie auf jeden Fall JSlint.

Oder:

Wenn Sie nach einem sehr hohen Standard für sich selbst oder das Team suchen, JSlint.

Wie Sie konfigurieren können fast Die gleichen Regeln in JSHINT wie in JSlint. Ich würde also argumentieren, dass es keinen großen Unterschied in den Regeln gibt, die Sie erreichen könnten.

Die Gründe, eine über einen anderen auszuwählen, sind also politischer als technischer.

Wir haben uns aus den folgenden Gründen endlich entschlossen, mit JSHINT zu gehen:

Scheint konfigurierbarer zu sein als JSINT.
Sieht definitiv eher gemeinschaftsgetrieben als eine Ein-Mann-Show (egal wie cool Der Mann ist).
JSHINT hat zu unserem Code -Stil übereinstimmt, das besser als JSlint ist.

Ich würde einen dritten Vorschlag machen, Google Closure Compiler (und auch die Schließungsinters). Sie können es online ausprobieren hier.

Der Verschluss -Compiler ist ein Tool, um JavaScript schneller herunterzuladen und zu ausgeführt zu werden. Es ist ein echter Compiler für JavaScript. Anstatt von einer Quellsprache zu Maschinencode zu kompilieren, kompiliert es von JavaScript zu einem besseren JavaScript. Es analysiert Ihr JavaScript, analysiert es, entfernt toten Code und schreibt um und minimiert, was noch übrig ist. Es überprüft auch die Syntax, variable Referenzen und Typen und warnt vor gemeinsamen JavaScript -Fallstricken.

Vorwort: Nun, das eskalierte schnell. Aber beschloss, es durchzuziehen. Möge diese Antwort Ihnen und anderen Lesern hilfreich sein.

Code deutlich

Während Jslint und Jshint gute Werkzeuge sind, habe ich im Laufe der Jahre zu schätzen, was mein Freund @ugly_syntax Anrufe:

kleinerer Konstruktionsraum.

Dies ist ein allgemeines Prinzip, ähnlich wie ein "Zen Monk", der die Entscheidungen einschränkt, die man treffen muss, kann produktiver und kreativer sein.

Daher mein aktueller Lieblings-JS-Code-Stil von Zero-Config:

Standardjs.

AKTUALISIEREN:

Fließen hat sich viel verbessert. Dabei können Sie Ihren JS -Typen hinzufügen, wodurch Sie viele Fehler verhindern. Es kann sich aber auch aus dem Weg halten, zum Beispiel, wenn Sie Untyped JS verknüpfen. Versuche es!

QuickStart / tl; Dr.

Hinzufügen standard Als Abhängigkeit von Ihrem Projekt

npm install --save standard

Dann in package.json, Fügen Sie das folgende Testskript hinzu:

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

Für snazzigere Ausgaben während der Entwicklung, npm install --global snazzy und rennen Sie es anstelle von npm test.

Hinweis: Geben Sie die Überprüfung gegen Heuristiken ein

Mein Freund, der auf den Beweis für den Entwurfsraum erwähnt wird Ulme Und ich ermutige Sie, diese Sprache auszuprobieren.

Wieso den? JS ist in der Tat von Lisp inspiriert, eine besondere Klasse von Sprachen, die zufällig ist ungetarn. Sprache wie Elm oder Pureskript sind tippt Funktionale Programmiersprachen.

Geben Sie Ihre Freiheit ein, damit der Compiler Sie überprüfen und leiten kann, wenn Sie gegen die Sprache oder die Regeln Ihres eigenen Programms verstoßen. unabhängig von der Größe (loc) Ihres Programms.

Wir hatten kürzlich einen Junior -Kollegen, der zweimal eine reaktive Schnittstelle implementiert: einmal in ELM, einmal in React; Schauen Sie sich einen Blick darauf an, wovon ich spreche.

Vergleichen Main.elm (Typed) ⇔ index.js (Untyped, keine Tests)

(Ps. Beachten Sie, dass der React -Code nicht idiomatisch ist und verbessert werden kann)

Eine letzte Bemerkung,

Die Realität ist, dass JS ist ungetarn. Wer bin ich, um vorzuschlagen? Typisierte Programmierung für dich?

Sehen Sie, mit JS sind wir in einer anderen Domäne: Befrei von Typen können wir leicht Dinge ausdrücken, die schwer oder unmöglich sind, einen richtigen Typ zu geben (was sicherlich ein Vorteil sein kann).

Ohne Typen gibt es jedoch wenig, um unsere Programme in Schach zu halten, sodass wir gezwungen sind, Tests und (zu einem geringeren) Codestil einzuführen.

Ich empfehle Ihnen, sich Lisp (z. ClojureScript) für Inspiration und investieren in das Testen Ihrer Codes. Lesen Der Weg des Substalls eine Idee bekommen.

Frieden.

Anstatt manuelle Linteinstellungen vorzunehmen, können wir alle Linteinstellungen oben in unserer JS -Datei selbst einbeziehen, z.

Deklarieren Sie alle globalen VARs in dieser Datei wie:

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

Deklarieren Sie alle Linteinstellungen wie:

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

Hoffe das wird dir helfen :)

Es gibt auch eine andere aktiv entwickelte Alternative - JSCs - Javascript -Codestil:

JSCS ist ein Codestil -Verlust für die programmgestützte Durchsetzung Ihres Style Guide. Sie können JSCs für Ihr Projekt mit über 150 Validierungsregeln ausführlich konfigurieren, einschließlich Voreinstellungen von populären Leitfäden wie JQuery, Airbnb, Google und mehr.

Es kommt mit mehreren Voreinstellungen mit dem Sie auswählen können, indem Sie einfach die angeben preset in dem .jscsrc Konfigurationsdatei und anpassen: Überschreiben, Aktivieren oder Deaktivieren von Regeln:

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

Es gibt auch Plugins und Erweiterungen für beliebte Redakteure.

Siehe auch:

Perfekter Code, null Aufwand

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow