Code-Linting

Heute war ein großartiger Tag, denn ich musste an der Integration von ESLint in unsere Codebasis arbeiten! Ich bin ein lustiger Code-Affe. Ich mag gute Codierungspraktiken wie Linting, Benutzer-/Technik-/Produktdokumentation, Tests, Zugänglichkeit und Sicherheit. Dabei handelt es sich um Themen, die normalerweise gegenüber dem Versand von funktionierendem Code eine untergeordnete Rolle spielen, da Code auch ohne die Dinge funktionieren kann, die ich als meine Programmierleidenschaften aufgeführt habe. Aber wenn alle diese Praktiken umgesetzt werden, wird der Code selten kaputt gehen (oder kaputt gehen) und ist ein zuverlässigerer Code. Warum nicht von Anfang an „zuverlässig funktionierender Code“ erstellen?

Warum ich Linting mag?

Linting hilft Ihnen, häufige Fehler frühzeitig zu erkennen. Linting-Regeln können schlechte Codierungspraktiken identifizieren, sodass Entwickler sie nicht in das Projekt einführen. Linting kann beispielsweise erkennen, wann const anstelle von let oder Shadow-Variablen verwendet werden sollte.

Das Verhindern von fehlerhaftem Code durch Linting ist die vielen Sprints zum Debuggen von schlechtem Code wert.

Meine Herausforderung

Wir hatten eine bestehende Codebasis, zu der viele Entwickler beitrugen. Der Code wies über 5.000 Linting-Verstöße auf, nachdem ich ESLint installiert und einen Bericht ausgeführt hatte. Ich suchte nach den besten Linting-Regeln für die Verwendung mit NextJS, TypeScript, A11y und JavaScript. Da es so viele Verstöße gab, beschloss ich, schrittweise nach Fehlern zu suchen. ESLint verfügt über eine automatische Korrekturfunktion, aber führen Sie diese niemals auf einer bereits vorhandenen Codebasis aus und erwarten Sie, dass sie funktioniert. Nein, nein, kein Jüngling. Wir müssen iterieren!

Ich habe die kritischen Regeln auf ❌ „Fehler“ und den Rest auf „Warnung“ oder „Aus“ gesetzt. Dann habe ich den Bericht erneut ausgeführt, um herauszufinden, was behoben werden sollte, bevor wir unseren Code erneut bereitstellen. Nachdem alle Fehler manuell behoben wurden und der Code erstellt werden konnte, habe ich unseren Komponententest durchgeführt, um sicherzustellen, dass wir immer noch ✅ alles bestanden haben. Gutes Linting sollte niemals den Code beschädigen. Bestenfalls soll Linting den Entwickler unterstützen. Wir helfen Nachwuchsentwicklern dabei, eine bessere Art des Codeschreibens zu erlernen, denn das müssen sie.

Nachdem alle meine Fehler identifiziert und behoben ODER ignoriert wurden, können wir sie bereitstellen und wissen, dass unser Code so gut ist, wie wir ihn „heute“ bekommen können. Nachdem die Codebasis nun repariert wurde, können wir in Zukunft „Auto-Magic-Fix“ verwenden und sind zuversichtlich, dass die Wahrscheinlichkeit, den Linting-Fehler zu beheben, bei 50/50 liegt.

Mein Lernen

Es scheint, dass ESLint erwachsen geworden ist! Einige weitere Codeformatierungsregeln werden nicht mehr unterstützt, die von einer Codeformatierungsbibliothek und nicht von einer Linting-Bibliothek verwaltet werden sollten. ESLint hat ab Version 9 viele Funktionen eingestellt und die meisten, wenn nicht alle, auf Stylistic umgestellt!

Ich verwende Prettier für die Codeformatierung und Typescript bietet Flag-Unterstützung in Stylistic, daher bin ich bei ESLint v8.53.0 geblieben, damit ich die überlegene Codeformatierung von ESLint beibehalten kann. Aber ich werde irgendwann in die 9 umziehen müssen, also hat das nur „die Sache auf den Kopf gestellt“.

Viel Spaß beim Codieren!

Das obige ist der detaillierte Inhalt vonCode-Linting. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!