English version: http://de.slideshare.net/mischah/js-linting-en
Untertitel: JS Syntax Überprüfung and Validierung
Session vom 3. Kasseler Webmontag.
Beantwortet die Frage »Was ist denn eigentlich dieses linting …« und stellt die Tools JSLint, JSHint und ESLint vor.
2. Michael Kühnel
- Macht Internet seit Netscape 4.7
- Ab April Frontend Developer bei Micromata
- Twitter: @mkuehnel
- Website: www.michael-kuehnel.de
3. Historie
Die (subjektiv) »wichtigsten« Tools
- JSLint (Release 2002)*
- JSHint (Initial release 2010)
- ESLint (Initial release 2013)
*JSLint nur aus historischen Gründen in der Liste
5. 1. Gleicher Zweck - Code
Qualitätsprüfung
Syntax Checker und Validator (JavaScript und JSON)
6. Code Qualitätsprüfung
Syntaxfehler die spätestens im Browser knallen
würden z.B.
- letztes Komma bei Object literals
- Fehlende oder unnötige Semikolons
- Fehlen von schließenden Klammern
- Tippfehler jeglicher Art
7. Code Qualitätsprüfung
Vermeidung von logischen Fehlern / Strukturellen
Problemen ➡️ Erhöhung der Maintainability z.B.
- Detection von unreachable Code
- Versehentliche globale Variable
- Nicht verwendete Parameter
- usw.
8. Code Qualitätsprüfung
Forcierung der Einhaltung von Coding Conventions
z.B.
- Einrückung
- Schreibweise von Konstruktoren
- Verwendung von eval()
- usw.
9. 2. Gleiche Funktionsweise
A. Findet Fehler
B. Beschreibt das Problem
C. nennt die Stelle im Quellcode (Zeilennummer)
11. 4. Sorgen nicht für
fehlerfreien Code
Minimieren aber die Fehlerquellen durch Einsatz an
sinnvoller Stelle im Workflow:
- beim Speichern
- als pre-commit hook
- Im Build Process
12. Es gibt keinen fehlerfreien
Code 😎
Zusätzlich empfehlenswert für Code-Qualität im
Team:
- Unit-Tests
- Funktionale Test
- Code Reviews
14. JSLint
- Autor: JavaScript Guru Douglas Crockford
(»Erfinder von JSON«, Entwickler von JSMin)
- Zitat von Crockford: »JavaScript is a sloppy
language, but inside it there is an elegant, better
language.«
- Intention: Enforcing der »Good Parts« von
JavaScript
- http://jslint.com
17. Hauptunterschiede zu JSLint:
- Community Driven (133 contributors)
- Testabdeckung des Quellcodes (Unit-Tests)
- Weniger opinionated (http://anton.kovalyov.net/p/why-jshint)
- Mehr Optionen (ein- und ausschaltbar)
- ECMAScript 6 support
- Konfiguration über JavaScript Kommentare oder Text-Dateien
(Empfehlung .jshintrc -> Arbeiten im Team + »Vererbung«)
JSHint ≠ JSLint
18. - Enforcing Options - für strikteren Code
- z.B. 'maxparams' Definition der maximalen Anzahl an
Parametern pro Funktion
- Relaxing Options - für tolerantere Überprüfung
- z.B. 'loopfunc' - Unterdrückt Warnungen bei Definition von
Funktionen innerhalb von Schleifen.
- Environment options - pre-defined globale Variablen für spezifische
Umgebungen
- z.B. 'jquery' - Vermeidet Warnung bei der Verwendung von '$'
und 'jQuery'.
JSHint - Überblick der
Optionen
19. Verfügbar als:
- Plugin für etliche Editoren
- Task für Grunt/gulp
- usw. Siehe Auszug auf http://jshint.com/install
- zum Ausprobieren auf der Website von JSHint
JSHint für alle
20. Pläne für den nächsten Major Release (3.0)
- Entfernung aller »style-related« Optionen und
Warnungen.
- Zitat: »Falls es Sinn macht sollten sie in optionale
Plugins überführt werden.«
- Plugin-System für Erweiterungen
Siehe http://www.jshint.com/blog/jshint-3-plans/
JSHint - Die Zukunft
23. ESLint
- Creator: Nicholas C. Zakas
- Intention:
- Noch flexibleres/ erweiterbares Linting Tool.
- Zunächst kompatibel zu JSHint - Sachen Regeln
- http://eslint.org
24. ESLint ≠ JSHint
Hauptunterschiede zu JSHint:
- Eine API für das einfache erstellen neuer Regeln (Plugin-System)
- Jede Regel ist ein Plugin (auch die mitgelieferten)
- Jede Regel ist abschaltbar!
- Noch mehr Regeln als JSHint
- Jede Regel kann je nach Bedarf Fehler oder Warnungen produzieren
- Config files im JSON Format oder YAML (weniger Schreibarbeit)
- »Schönere« Ausgabe im Terminal 😘
25. ESLint - Optionen für
Konfiguration
- Environments
- Laufzeitumgebung (Browser/Node/Rhino).
- Jede Umgebung definiert ein Set an globalen Variablen und
Regeln die per Default aktiviert sind.
- Globals
- Weitere selbst definierte globale Variablen
- Rules
- Welche regeln sind aktiviert und welcher Fehler-Level ist
definiert.
26. ESLint - Überblick der
Regeln
1. Possible Errors:
- Mögliche Fehler im Code
- z.B. 'no-dupe-keys' – Hinweis auf doppelte Keys bei Object literals
2. Best Practices:
- Hinweise auf Code-Fragemente die man lieber anders schreiben sollte.
- z.B. 'wrap-iife' – Hinweis darauf, dass man sich selbst aufrufende Funktionen mit
Klammern umschließen sollte.
3. Strict Mode:
- Regeln die den Strict Mode betreffen (ECMAScript5)
- z.B. 'no-extra-strict' – Warnung bei Verwendung von "use strict" wenn bereits in strict
mode.
27. ESLint - Überblick der
Regeln
4. Variables:
- Regeln die mit der Deklaration von Variablen zu tun haben
- z.B. 'no-shadow' – Warnung bei Deklaration von Variablennamen die bereits in einem
äußeren Scope verwendet werden.
5. Node.js:
- Node.js spezifische Regeln
- z.B. 'no-process-exit' Warnung bei Verwendung von process.exit()
6. Stylistic Issues:
- Regeln die »nur« coding Style betreffen
- z.B. 'no-new-object' - Warnung bei Verwendung des Object Constructors: new
Object()
28. Fazit
ESLint – The way to go 🔥 – trotz frühem Entwicklungsstand (0.4.2)
- Größtes Set an Regeln die am flexibelsten zu konfigurieren sind
- Zukunftssicher in Sachen »Style related Warnings«
- Pluggability (z.b. für firmeninterne Regeln zur Einhaltung von
Coding Guidelines)
- Vermutlich schon bald die größte Entwicklergemeinde hinter
dem Projekt
- Neben Grunt auch für exotischer JS-Build Tools wie Broccoli als
Module erhältlich ; ] Siehe http://eslint.org/docs/integrations