Entdecke die Potentiale des Lintings in der Entwicklung mit ESLint, Stylelint, SonarLint, Sheriff und Prettier. Fehlerkorrekturen, Codeanalyse und effizientere Projekte – Qualität auf einem neuen Niveau.

Die Welt der Software-Entwicklung ist dynamisch und anspruchsvoll – mit einer Vielzahl von Frameworks, Bibliotheken und Technologien, die sich ständig weiterentwickeln. Doch selbst mit dem besten Know-how und den richtigen Tools kann die Sicherstellung der Codequalität eine Herausforderung darstellen. Hier kommt die Macht des Lintings ins Spiel. Linting-Tools wie ESLint, Stylelint, SonarLint, Sheriff und Prettier bieten nicht nur Fehlerkorrekturen, sondern auch eine umfassende Code-Analyse, die die Qualität deiner Codebase auf ein neues Niveau hebt und sicherstellt, dass sie aufrechterhalten wird.

Linter haben mir in der Praxis geholfen, besseren Code zu schreiben sowie unzählige Minuten des Betrachten von Changes in einem Merge-Request erspart. Die darauf zurückzuführen waren, dass sich der Zeilenumbruch geändert hatte.

In diesem Artikel erkunden wir, warum Linting so wichtig ist, welche Vorteile es bietet und wie diese Tools dazu beitragen, Projekte effizienter und qualitativ hochwertiger zu gestalten.

Linting?

Ein Linter ist ein Programm, das dem Entwickler Feedback gibt zu potentiellen Programmierfehlern, Stilproblemen oder Anti-Pattern¹. Abb. 1 zeigt dir einen Linter in Aktion.

Vorteile

Doch bei welchen Problemen hilft uns Linting eigentlich? Hier hast du für jeden Finger an deinen Händen einen Vorteil, falls du mal wieder mit deinem Projektmanager diskutieren musst, ob sich die investierte Zeit lohnt 😉.

1. Aufzeigen von Syntaxfehlern: Linter erkennen und markieren Syntaxfehler, die sonst unbemerkt bleiben könnten.
2. Logische Fehler: Sie helfen dabei, logische Fehler wie niemals ausgeführte If-Blöcke zu entdecken.
3. Automatisierte Umsetzung von Code-Styling: Durch Linting können Code-Styling-Regeln wie maximale Zeilenlänge oder Einrückungen automatisiert umgesetzt werden.
4. Vermeidung von Anti-Pattern: Linter helfen dabei, Anti-Patterns wie ungenutzte Variablen zu vermeiden.
5. Verbesserung der Code-Qualität: Der Code wird durch Linting optimiert und aufgeräumt.
6. Lerneffekte für Entwickler: Durch das Feedback des Linters lernen Entwickler kontinuierlich dazu.
7. Früherkennung potenzieller Fehler: Bugs werden bereits in der Entwicklungsphase erkannt, was Zeit spart und Bugs im fertigen Produkt reduziert.
8. Effizientere Code-Reviews: Einheitliche Formatierungsregeln führen zu effizienteren Code-Reviews und reduzieren unnötige Änderungen in Merge-Requests.
9. Sicherheit und Konsistenz: Neuer Code unterliegt denselben Qualitätsrichtlinien wie der bereits bestehende Code.
10. Zusammenarbeit im Team: Wenn man sich auf gemeinsame Standards geeinigt hat, erspart dies viele Diskussionen in der Zukunft - Wann eine Zeile umbricht oder wie viele Leerzeichen ein Tab sein sollten, ist ein für alle Mal geklärt.

Tools

Das ist eine Übersicht über Linting-Tools, die ich in meiner täglichen Arbeit nutze. Feedback ist natürlich gerne gesehen ✉. Ich schreibe hier über die Konzepte und Ideen hinter den Tools zur statischen Codeanalyse. Wenn du eine konkrete Umsetzung sehen möchtest, schau dir meinen Artikel Angular-Linting konfigurieren an.

ESLint

Hierbei handelt es sich um ein OpenSource-Linting Projekt (eslint.org). Es ist sehr individuell konfigurierbar und hilft, Probleme zu finden und zu lösen. Dies können Bugs, nicht umgesetzte Best Practices oder CodeSytling-Probleme sein ².

Das Herzstück von ESLint sind seine Regeln bzw. Rules. Eine Rule definiert eine bestimmte Erwartung an den Code. Ein Beispiel für eine solche Erwartung wäre, einen Linting Fehler zu erzeugen, wenn ein constructor ein return-Statement enthält, siehe Abb. 1.

Erreicht wird dies durch die no-constructor-return Regel. Sie lässt sich einfach in die eslintrc.{js,yml,json}, die ESLint-Konfigurationsdatei, einbinden.

ESLint zeigt jedoch sein wahres Potenzial erst, wenn bereits vorhandene Regelsets integriert werden. Ein verbreitetes Regelset ist eslint:recommended, das eine Vielzahl von bewährten Regeln enthält. Die genauen Regeln, die dieses Set aktiviert, sind in der offiziellen ESLint-Dokumentation nachzulesen.

Prettier

Bei Prettier handelt es sich auf den ersten Blick eher um einen Formatter als um einen Linter³. Es kümmert sich um:

• Einrückungen und Leerzeichen
• Zeilenumbrüche
• Kommas und Semikolons
• Stringformatierung

Ebenfalls bietet Prettier den Vorteil, dass die Konfigurationsmöglichkeiten der Formatierung auf ein Minimum beschränkt sind. Warum dies von Vorteil ist, wird vom Prettier-Team in ihrem Artikel why-prettier? umfassend erläutert.

Prettier 🆚 eslint-plugin-prettier

Prettier lässt sich auf zwei unterschiedlichen Wegen einbinden, die aber beide das gleiche Endergebnis liefern.

Prettier

Ein Ansatz ist das npm-package prettier.

Vorher:

const blog = { name: 'j1n', url: 'https://j1nk3e.de/', articles: 400, visits: 2, faviconDir: 'assets/favicon.ico' }

Nachher:

const blog = {
    name: 'j1n',
    url: 'https://j1nk3e.de/',
    articles: 400,
    visits: 2,
    faviconDir: 'assets/favicon.ico',
}

Die Codezeilen, die der Prettierformatierung widersprechen, werden angepasst und nicht wie in Abb. 1 aufgezeigt.

Eslint-plugin-prettier

Der andere Weg führt über ESLint. Es ermöglicht uns, die Prettierrules als Extensions über ESLint auszuführen. Besonders einfach mit dem npm-package eslint-plugin-prettier. Jede verletzte Prettierregel würde uns ESlint dann wieder markieren wie in Abb. 1.

Allerdings ist zu beachten, dass die Prettierrules damit nicht auf Stylesheets angewendet werden.
Wie du auch das schaffst, kannst du im Stylelintabsatz Stylelint-prettier nachlesen.

EditorConfig

Ähnlich zu Prettier hilft uns die .editorconfig dabei, einen gleichbleibenden Formatierungsstil einzuhalten. Es können unterschiedliche Regeln definiert werden, die dann die jeweiligen IDE-Einstellungen überschreiben⁴. Im EditorConfig Github-Wiki findest du eine Übersicht darüber, welche Regeln konfigurierbar sind. Hierbei kommt es auf die IDE an, ob ein Plugin benötigt wird oder nicht (Übersicht).

Unterschied zu Prettier

Der Unterschied zu Prettier besteht darin, dass EditorConfig die Einstellungen der IDE bestimmt. Nehmen wir als Beispiel die indent_size (EditorConfig) bzw. tabWidth (Prettier). In der .editorconfig können wir die indent_size auf indent_size=10 setzen. Ein Tabulator entspricht dann beispielsweise 10 Leerzeichen. Nutzen wir in der IDE nun Tab, werden 10 Leerzeichen gesetzt. Das widerspricht der Prettierregel "tabWidth": 4 (gesetzt in .prettierrc). Normalerweise berücksichtigt Prettier die .editorconfig, allerdings kann nicht jede Regel aus der .editorconfig auf die Konfigurationmöglichkeiten von Prettier übertragen werden.

Zusammengefasst besteht der Unterschied darin, dass die Editorconfig den Code beeinflusst, den wir schreiben, während Prettier den Code formatiert, den wir geschrieben haben.

Prettier u. EditorConfig in Kombination

Die optimale Nutzung von EditorConfig und Prettier ergibt eine effektive Synergie. Wenn wir unsere EditorConfig-Einstellungen entsprechend auf Prettier ausrichten, gewährleisten wir, dass unser Code während des Schreibens direkt korrekt formatiert wird (siehe das Beispiel mit indent_size). Dadurch wird eine erneute Formatierung durch Prettier überflüssig. Daraus folgt, dass Prettier “nur” noch Codezeilen markieren wird, die nicht von EditorConfigregeln abgedeckt werden.

Sheriff

Sheriff erzwingt Modulgrenzen und Abhängigkeitsregeln in TypeScript. Es ist ebenfalls eine Erweiterung für ESLint.

Modulgrenzen

Jeder Ordner, der eine index.ts beinhaltet, ist als Modul zu betrachten. So auch die folgende Ordnerstruktur.

project
│
└───feature1
│   │   internal.service.ts
│   │   index.ts
└───feature2
    │   service2.service.ts

In der Datei internal.service.ts wird eine Funktion exportiert. Die index.ts exportiert wiederum den internal.service.ts. Würde service2.service.ts direkt aus internal.service.ts importieren, würde dies über ESLint, durch die Sheriffrules, eine Markierung durch den Linter hervorrufen.

// in service2.service.ts

// deep-import Fehler
import { FUNCTION } from '../feature1/internal.service';
// valider import über index.ts
import { FUNCTION } from '../feature1';

Abhängigkeitsregeln

Sheriff ermöglicht die Konfiguration von Zugangsregeln zwischen Modulen. Dies ist besonders praktisch für die Umsetzung von Domain-driven Design (DDD). Ein Beispiel ist in dem Sheriff-GitHub-Repo zu finden.

Schau dir gerne das YouTube-Video an, in dem einer der Entwickler Sheriff vorstellt.

Stylelint

Stylelint ist ein leistungsfähiges Linting-Werkzeug, das speziell für die Prüfung von Stylesheet-Dateien entwickelt wurde. Es bietet eine Vielzahl von Regeln und Konfigurationsoptionen, um sicherzustellen, dass der Code den definierten Codierungsstandards entspricht⁵. Wie auch schon bei ESLint lassen sich Regelsets oder Plugins importieren, was Stylelint gewissermaßen zu dem ESLint für Stylesheet-Datein macht.

Stylelint-prettier

Stylelint muss ebenfalls von Seiten des Regelsets mit Prettier abgestimmt werden (gegenseitig widersprechende Regeln), falls du Stylelint unterhalb von Version 15 nutzt, dies kann durch das npm-package stylelint-prettier schnell erreicht werden. Andernfalls sind ab höheren Versionen die widersprechenden Regel bereits deaktiviert.
Ebenfalls nutzen wir das Package, um die Prettierrules auch auf Stylesheets anzuwenden.

Stylelint-order

Bei stylelint-order handelt es sich um eins der importierbaren Regelsets für Stylelint. Wie der Name schon sagt, bestimmt dies die Reihenfolge der CSS-Eigenschaften in Stylesheets. Es gibt mehrere Konfigurationen, auf welcher Grundlage die Anordnung der CSS-Eigenschaften erfolgen soll.

Dies ist ein wirklich großer Vorteil, wenn man mit mehreren Entwicklern an einem Projekt arbeitet oder mit älterem Code, da man immer den gleichen Ablauf von Kommandos in den Stylesheets hat.

Sonarlint

Last but not least - SonarLint, ein Tool der Firma Sonar. Sonarlint ist ein besonders umfangreiches Tool. Es geht noch ein bisschen weiter als ESLint, welches den Fokus eher auf Javascript und Typescript legt². Sonarlint analysiert u.a auch HTML-Seiten auf Code-Smells, ist also umfangreicher als ESLint, wenn es aber auch einige Überschneidungen gibt.

<table>
</table>

Der oben stehende Code würde z.B. gelinted werden, weil der table kein <caption>- bzw. kein <th>-Element beinhaltet.

Fazit

Wenn man die Vorteile von Lintern betrachtet, kommt man nicht umhin festzustellen, dass - ob Solo- oder Großprojekt -, linting ein Teil des Fundaments eines Projektes und damit unerlässlich ist. Zum einen ist es die kontinuierliche Aufrechterhaltung von möglichst hohen Standards, die der Code erfüllen muss und zum anderen die massive Zeitersparnis. Weiterhin ist auch der Faktor des Lernens durch den Linter und z.B. des dauerhaften Vermeidens von Code Smells nicht zu unterschätzen. Mit meiner Toolauswahl decken wir einen Großteil der Dateien ab und lassen kaum noch Platz für vermeidbare Fehler.

Ich hoffe, ich konnte dich überzeugen, ab jetzt Linter einzusetzen. Falls ja, empfehle ich dir Linter “on-save”, in einer pre-commit-hook und nochmal in der CI/CD deines Projekts auszuführen. Bleiben wir gespannt, was neue Technologien in diesem Bereich leisten werden. Ich könnte mir sehr gut vorstellen, dass KI die Liste der Linterbenefits erweitert.

Hast du noch Fragen oder vielleicht sogar Ideen für weitere Linter, die ich aufnehmen sollte? Schreibe mir gerne eine E-Mail.

Quellen