© GoodStudio/Shutterstock.com
Per Anhalter durch den JavaScript-Dschungel

ESLint – it will hurt your feelings


ESLint ist eines der wichtigsten und wahrscheinlich auch eines der am häufigsten unterschätzten Werkzeuge in der JavaScript-Welt. Ich habe mittlerweile eine richtige Hassliebe zu diesem kleinen Helferlein entwickelt. Habe ich es in einem Projekt aktiviert, geht es mir mit seinem Genörgel ständig auf die Nerven, fehlt es aber, macht das ganze Entwickeln nur halb so viel Spaß, weil immer das ungute Gefühl mitschwingt, dass sich im Code irgendein Antipattern versteckt, das mir später noch auf die Füße fällt.

ESLint ist auch eines der wenigen Werkzeuge, um die es kaum Diskussionen gibt. In der JavaScript-Welt ist es ja üblich, für jedes Problem gefühlt hundert verschiedene Lösungen zu haben. Für die statische Codeanalyse hat sich ESLint jedoch klar durchgesetzt. Bei einer kurzen Recherche stoße ich zwar auch auf Werkzeuge wie JSCS oder TSLint, beide wurden jedoch mit ESLint gemergt beziehungsweise zugunsten von ESLint eingestellt. Mit JSLint und JSHint gibt es dann aber durchaus Konkurrenten. Werfen wir hier einen Blick auf die Downloadzahlen, sehen wir jedoch schnell, dass JSLint mit seinen weniger als 30 000 wöchentlichen Downloads aus dem npm Repository kaum eine Rolle spielt, was vor allem an seinem strikten und unflexiblen Charakter liegt und daran, dass das Werkzeug mittlerweile deutlich in die Jahre gekommen ist. JSHint ist da schon besser, weil es konfigurierbarer und nicht ganz so opinionated ist. Aber die gut 440 000 Downloads sind kein Vergleich zu den gut 16 Millionen Downloads pro Woche bei ESLint.

Bevor wir uns also gleich auf ESLint stürzen, sollten wir uns noch ganz kurz die Frage stellen: Warum binde ich mir ein Werkzeug ans Bein, das mich ständig kritisiert? Hierzu ein Spruch, der mir seit vielen Jahren im Kopf geblieben ist, wenn es um Codeanalysewerkzeuge geht: „It will hurt your feelings.“ Das ist der Claim von JSLint, dem Urvater der statischen Codeanalyse in JavaScript. Und was soll ich sagen, ja, meine Gefühle sind von diesen Tools bereits nachhaltig verletzt worden. Aber sind wir Entwickler nicht alle nur Menschen? Und als solche sind wir nicht immer gleich gut gelaunt und gleich aufmerksam. Das merkt man nicht nur, wenn man sich mit dem grumpy Dev des Teams an der Kaffeemaschine unterhält, sondern sieht es leider auch immer wieder am Quellcode einer Applikation. Da bleiben Sprüche wie „Na, war es wieder spät gestern?“ nicht aus. Aber sollte man dem Quellcode wirklich ansehen, an welchem Wochentag, zu welcher Uhrzeit und in welcher Stimmung er geschrieben wurde? Ich denke nicht. Der Code einer Applikation sollte aus einem Guss sein. Egal, ob gerade die Senior-Oberchef-Architektin oder der Praktikant am Werk waren: Der Code sieht immer gleich aus und ist denselben Regeln unterworfen.

Um dieses Ziel zu erreichen, gibt es eine ganze Menge von Hilfsmitteln, zu denen sicherlich nicht das öffentlich an den Pranger stellen von Personen gehört, die gegen Regeln verstoßen. Sehr wohl sind aber Codereviews ein probates Mittel. Aber bevor sich eine Person die Mühe macht, das Codekunstwerk zu begutachten, sollten bitte die größten Schnitzer ausgebügelt sein. Da helfen nur Werkzeuge, mit ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang