Wie können ihr euren Code-Garten mit GenAI ganz einfach verwalten?

Genau wie Gärtnerinnen oder Gärtner Pflanzen beschneiden und formen, um einem bestimmten Entwurf zu folgen, verwenden Entwicklerinnen und Entwickler Linting-Tools, um Architekturrichtlinien durchzusetzen und sicherzustellen, dass ihr Code den Best Practices entspricht. Beide erfordern kontinuierliche Pflege, um Schwachstellen zu identifizieren – seien es ungesunde Pflanzen oder inkonsistenter Code – und Maßnahmen zu deren Behebung zu ergreifen. Mit den richtigen Tools können Entwicklerinnen und Entwicker eine solide Codegrundlage schaffen und sicherstellen, dass die Codebasis auf gesunde, wartbare und skalierbare Weise wächst, so wie ein gut geplanter Garten mit der Zeit gedeiht.

Man braucht keinen Doktortitel in maschinellem Lernen, um mit GenAI etwas Großartiges zu schaffen. Wenn ihr als Entwicklerin oder Entwickler eine interessante Idee habt, ist das mehr als genug. Ein Beispiel: Wir haben eine kostenlose App namens Lint-E entwickelt, mit der ihr benutzerdefinierte ESLint-Regeln mithilfe eines der Modelle von OpenAI, GPT-4o, generieren könnt. Und ja – ihr könnt diese Regeln sogar direkt in der Benutzeroberfläche ausführen und validieren.

Bringt euren eigenen OpenAI-Schlüssel mit, erstellt eine Regel, klickt auf „Lint Code” und schon testet ihr eure benutzerdefinierte, KI-generierte Linting-Regel live in der Benutzeroberfläche. Wir haben sogar Angular-Unterstützung hinzugefügt, damit Sie mit frameworkspezifischen Regeln experimentieren können.

Wie funktioniert das alles? Schauen wir uns das einmal genauer an.

Linting und ESLint 101

Linting ist der Prozess der Analyse von Quellcode, um Programmierfehler, stilistische Probleme oder verdächtige Konstrukte zu markieren. Stellt euch das wie eine Rechtschreibprüfung für euren Code vor – nur viel intelligenter. Es hilft Teams dabei, saubereren und konsistenteren Code zu schreiben. Linting ist eine dieser Funktionen, die euch als Entwicklerinnen und Entwickler 50 Mal am Tag still und leise das Leben rettet. Hier sind einige praktische Anwendungsfälle, in denen Linting wirklich glänzt:

Fehler frühzeitig erkennen

• Beschreibung: Erkennt häufige Fehler, bevor sie zu Laufzeitfehlern führen.
• Beispiel: Versehentliche Verwendung einer Zuweisung anstelle eines Vergleichs in einer Bedingung.

Konsistenz des Codestils durchsetzen

• Beschreibung: Stellt sicher, dass alle Entwicklerinnen und Entwickler denselben Formatierungs- und Codierungsstil verwenden.
• Beispiel: Konsistente Verwendung von Anführungszeichen, Einrückungen, Leerzeichen oder Semikolons.

Verhindert schlechte Praktiken

• Beschreibung: Verbietet riskante, unsichere oder veraltete Codierungsmuster.
• Beispiel: Blockieren von console.log, veralteten APIs oder unsicheren Funktionen.

Verbessert eure Codequalität

• Beschreibung: Fördert saubereren, lesbareren und wartungsfreundlicheren Code.
• Beispiel: Vorschlagen von einfacheren Ausdrücken oder konsistenter Benennung.

Benutzerdefinierte projektspezifische Regeln

• Beschreibung: Wendet Lint-Regeln basierend auf den Anforderungen eurer spezifischen Anwendung oder eures Teams an.
• Beispiel: Durchsetzung von Namenskonventionen, Anforderung von Dokumentation oder framework-spezifischen Regeln.

Automatisierte Prüfungen in CI/CD

• Beschreibung: Verhindert, dass schlechter oder nicht konformer Code in Hauptzweige integriert wird.
• Beispiel: Blockieren von Pull-Anfragen, die während der kontinuierlichen Integration die Lint-Prüfung nicht bestehen.

Schulung und Einarbeitung

• Beschreibung: Helft neuen oder unerfahrenen Entwicklerinnen und Entwicklern, Best Practices zu erlernen, indem ihr Fehler frühzeitig erkennt.
• Beispiel: Markiert häufige Anti-Patterns oder nicht idiomatischen Code.

Durchsetzung architektonischer Grenzen

• Beschreibung: Wahrt die richtige Struktur und Trennung der Aufgabenbereiche in großen Codebasen.
• Beispiel: Beschränkt Importe zwischen Schichten, verhindert zirkuläre Abhängigkeiten oder setzt modulare Grenzen durch.

ESLint1 ist der Linter der Wahl für JavaScript und TypeScript. Es analysiert euren Code und wandelt ihn in einen sogenannten Abstract Syntax Tree (AST) um, eine strukturierte, baumartige Darstellung des Codes. Anstatt euren Code nur als Text zu behandeln, betrachtet ESLint die Struktur – beispielsweise wo Funktionen beginnen und enden, welche Variablen deklariert sind und welche Ausdrücke verwendet werden.

Ein AST einer beliebigen Programmiersprache ist im Grunde wie die Grammatik einer natürlichen Sprache – ja, genau das mit Konjunktionen und Adverbien. Die Sätze können inhaltlich sehr unterschiedlich sein, wie zum Beispiel „Honig ist unverderblich.“ (Archäologen haben in ägyptischen Gräbern 3.000 Jahre alten Honig gefunden, der noch immer essbar ist!) und „Bananen enthalten Strahlung.“ (Bananen enthalten ein radioaktives Isotop namens Kalium-40). Dennoch bestehen beide Sätze aus einem Substantiv, einem Verb und einem Objekt. In JavaScript lautet die Funktion:

	
	private function sum(a, b): number {
	     return a + b
	}
	

Als AST im JSON-Format würde das etwa so aussehen:

	
	{
	"type": "FunctionDeclaration", 
	"accessibility": "private" 
	"id": {"name": "sum"...}, 
	"params": [ 2 elements... ], 
	"returnType": {"type": "TSNumberKeyword"...}, 
	"body": {     
	  "type": "BlockStatement",    
	  "body": [        
	    {          
	      "type": "ReturnStatement",           
	      "argument": {              
	        "type": "BinaryExpression"              
	        "operator": "+",              
	        "left": {"name": "a"...},              
	        "right": {"name": "b"...}           
	     }         
	    }     
	   ]   
	  }
	}
	

Wenn ihr euer Programm erkunden möchtet, probiert einfach den öffentlichen AST Explorer2 aus. Euer zu erkundendes Programm kann auch in anderen allgemeinen Programmiersprachen (GPLs) wie Rust oder Python oder domänenspezifischen Sprachen (DSLs) wie CSS geschrieben sein. ESTree ist eine Spezifikation zur Darstellung von JavaScript-Syntaxbäumen in einem Standard-JSON-Format, das häufig von Tools wie Linters, Compilern und Formatierern zur Analyse und Bearbeitung von Code verwendet wird. Python hat beispielsweise ein eigenes ast-Modul, während Java keine einzige universelle Spezifikation wie ESTree hat. Stattdessen definieren Tools wie Eclipse JDT3, ANTLR4 und JavaParser ihre eigenen AST-Strukturen für Java-Code.

ASTs erleichtern auch die Codetransformation, beispielsweise das Transpilieren neuerer JavaScript-Syntax in ältere Versionen. Sie unterstützen automatisiertes Refactoring, Codeoptimierung und Fehlererkennung während der Kompilierung. Viele IDEs verwenden ASTs für Funktionen wie Autovervollständigung und Fehlerhervorhebung in Echtzeit. Darüber hinaus helfen ASTs bei der Erstellung von Dokumentationen, der Erkennung von Sicherheitslücken und ermöglichen statische Typprüfungen in Sprachen wie TypeScript. Sie werden auch in Testabdeckungstools verwendet, um ungetesteten Code zu identifizieren. Insgesamt spielen ASTs eine wichtige Rolle bei der Verbesserung der Code-Qualität und -leistung sowie bei der Ermöglichung sprachübergreifender Tools wie Prettier und ESLint, was sie in modernen Entwicklungsworkflows unverzichtbar macht.

ESLint analysiert den Quellcode und wandelt ihn in einen AST um, der die Codestruktur darstellt. Anschließend wendet es eine Reihe vordefinierter oder benutzerdefinierter Regeln auf den AST an, um potenzielle Probleme oder Stilverstöße zu identifizieren. Schließlich meldet es alle Fehler oder Warnungen und hilft Entwicklern so, konsistenten und fehlerfreien Code zu erhalten.

Jetzt denkt ihr wahrscheinlich: "Das interessiert mich nicht. Ich habe diese Regeln in meinem Projekt und sie funktionieren, weil jemand einmal ESLint konfiguriert hat.". Und ja, ESLint verfügt über einige großartige Kernregeln und eine Standardeinstellung für jede Codierungsrichtlinie, die grundsätzlich überall als Best Practice angesehen werden sollte. Es gibt weitere Plugins wie das Angular ESLint Plugin5, das euch nicht nur frameworkspezifische Funktionen bietet – zum Beispiel ist @Component normalerweise nicht Teil der JavaScript-Grammatik –, sondern auch anwendungsspezifische Regelsätze. Natürlich benötigt ihr auch das Typescript ESLint Plugin6, wenn ihr TypeScript lintet, da es eine Obermenge von JavaScript ist. Daher unterscheidet sich auch hier die Grammatik. Einige ausgefallene Add-on-Regelsätze für eure Lint-Regelsammlung werden von Plugins wie dem ESLint Security Plugin7 oder dem Unicorn ESLint Plugin8 bereitgestellt. Letzteres führt zwar nicht zu mehr Einhörnern in eurer Codebasis, bietet aber eine schöne Auswahl nützlicher Linting-Regeln.

Obwohl wir all diese praktischen Kernregeln und Plugins haben, seid ihr individuell, ebenso wie euer Projekt, euer Team, eure Architektur und eure Codebasis. Benutzerdefinierte Namenskonventionen, große Änderungen oder architektonische Einschränkungen erfordern möglicherweise einen auf eure Bedürfnisse zugeschnittenen Regelsatz. Und natürlich könnt ihr einfach euer eigenes Plugin erstellen. Das hat den schönen Nebeneffekt, dass ihr nicht von den Plugins anderer abhängig seid, die euch tiefer in den Strudel von Updates, Versionskonflikten, Regelkonflikten, bahnbrechenden Änderungen und Leistungseinbußen ziehen.

Um eine benutzerdefinierte ESLint-Regel zu schreiben, müsst ihr verstehen, wie ESLint Code in einen abstrakten Syntaxbaum parst und wie man in diesem Baum navigiert, um bestimmte Muster zu erkennen. Außerdem müsst ihr die Syntax von JavaScript kennen und wissen, wie die Regel-API von ESLint funktioniert, um die Logik für eure Regel zu definieren. Das kann eine Herausforderung sein, denn das Schreiben effektiver Regeln erfordert sowohl ein tiefes Verständnis der Struktur der Sprache und des ESLint-Frameworks als auch den Umgang mit Randfällen und die Sicherstellung, dass eure Regel sowohl genau als auch effizient ist. Also ja, kommen wir zurück zu diesen Plugins.

Oder wir rufen GenAI zu Hilfe!

Sorry für das Buzzword!

Wir beschäftigen uns mit GenAI. Das klingt einfach super schick - für Vertriebsmitarbeitende.

Für die meisten Entwicklerinnen und Entwickler bedeutet „sich mit generativer Künstlicher Intelligenz beschäftigen” in Wirklichkeit, ein auf dem Markt erhältliches Modell zu verwenden, indem sie es direkt oder indirekt mit Prompts versorgen. Wenn ihr Glück habt, kann die Entwicklerin oder der Entwickler begründen, warum sie oder er sich speziell für dieses bestimmte Modell, diese Prompt-UI, diese IDE-Integration oder diese Konfiguration entschieden hat. Die allgemeinen Grundlagen von GenAI, Modellen, Architekturen und Aufgaben, in denen sie sich auszeichnen sowie Grundkenntnisse im Prompt Engineering zu kennen, ist bereits ein großer Gewinn, den sich die meisten Entwickerlinnen und Entwickler privat durch Recherchen im Internet aneignen müssen, anstatt von ihren Unternehmen geschult zu werden. Auch wir sind Amateurleser.

Softwareentwicklerinnen und -entwickler tun Folgendes:

• Sie haben eine großartige Idee,
• sie schreiben fantastische Software und
• sie wählen das passende Modell aus und fügen es ihrer Software hinzu, um genau definierte Aufgaben zu lösen.

Die Entscheidung fiel auf GPT-4o. Dabei handelt es sich um ein großes Sprachmodell, genauer gesagt um einen Decoder-Only-Transformer. Decoder-Only-Modelle wie GPT-4o sind beliebt, da sie sich gut für die Textgenerierung eignen und dank ihrer einheitlichen Architektur bei der Inferenz effizient sind. Im Gegensatz zu Encoder-Decoder-Modellen (wie T5), die einen separaten Encoder zur Verarbeitung der Eingabe und einen Decoder zur Generierung der Ausgabe verwenden, führen Decoder-only-Modelle beide Aufgaben innerhalb desselben Mechanismus aus – sie generieren die Ausgabe Token für Token und berücksichtigen dabei den Eingabekontext. Dieses Design ist für Generierungsaufgaben oft einfacher und schneller, wenn auch nicht unbedingt kleiner in der Modellgröße.

Diese Effizienz ist ein Grund, warum Decoder-Only-Modelle besonders effektiv für Aufgaben wie das Schreiben benutzerdefinierter ESLint-Regeln sind. Sie generieren Code Schritt für Schritt und sagen jeden Teil auf der Grundlage der Eingabeaufforderung und der vorherigen Token voraus – ohne dass eine separate Verständnisphase wie bei Encoder-Decoder-Modellen erforderlich ist. Dies macht sie ideal für offene Generierungsaufgaben und bietet ein hervorragendes Gleichgewicht zwischen Leistungsfähigkeit und Kosteneffizienz. GPTs sind nicht die Antwort auf alles, aber in diesem Fall treffen sie genau den Nagel auf den Kopf.

Das Tool: Lint-E

Lint-E (in Kürze hier öffentlich verfügbar: lint-ai.com) ist ein Tool, mit dem ihr benutzerdefinierte ESLint-Regeln schreiben sowie diese innerhalb von Sekunden validieren und exportieren könnt. Die App besteht aus einem Node.js-Backend und einem Angular-Frontend. Ihr bringt euren OpenAI-API-Schlüssel mit, der in der API-Anfrage an das GPT verwendet wird. Euer API-Schlüssel wird im NGXS-Speicher gespeichert9. In NGXS werden die im Speicher gespeicherten Daten im JavaScript-Speicher auf der Client-Seite aufbewahrt, das bedeutet, sie werden im Speicher des Browsers (genauer gesagt in der JavaScript-Laufzeitumgebung) gespeichert. Standardmäßig ist der Status nicht persistent, das heißt, wenn die Seite neu geladen oder der Browser geschlossen wird, wird Ihr API-Schlüssel nicht gespeichert. Es ist keine zusätzliche Persistenz implementiert (zum Beispiel localStorage, sessionStorage oder ein benutzerdefinierter Persistenzmechanismus). Ihr erhaltet eine vollständige Benutzeroberfläche mit Feldern zum Ausfüllen:

• Beschreibung (obligatorisch): Beschreibt, was die Regel bewirken soll und warum ihr sie benötigt. Je mehr und je genauer, desto besser.
• Fehlerbeispiel: Gebt ein Beispiel, wann die Regel einen Fehler auslösen würde (zum Beispiel die Regel: „Verwendet eval nicht!”, schlechtes Beispiel: „eval(anyCode)”).
• Framework: Ihr könnt natürlich auch Regeln speziell für zum Beispiel React oder Vue erstellen. Derzeit unterstützen wir jedoch keine Überprüfung dieser Frameworks. Angular wird vollständig unterstützt.
• Kategorie: Wenn ihr eure eigenen ESLint-Plugins schreibt, möchtet ihr die Regeln vielleicht nach Themen sortieren, um die Wartbarkeit, Lesbarkeit und Organisation des Codes zu verbessern. Die Kategorie wird im Abschnitt docs in den Metadaten der Regel platziert. Um die Struktur einer Regel zu überprüfen, schaut unter „Benutzerdefinierte Regeln – ESLint – Pluggable JavaScript Linter”10 nach.
• Typ: In ESLint können Regeln als Problem (Regeln, die Codeprobleme erkennen, die behoben werden müssen), Vorschlag (Regeln, die Verbesserungen empfehlen, ohne sie zu erzwingen) oder Layout (Regeln, die die Formatierung des Codes und die Konsistenz des Stils erzwingen) kategorisiert werden. Der Typ ist ebenfalls Teil der Metadaten der Regel.
• Behebbar: Aktiviert das Kontrollkästchen, wenn ihr möchtet, dass die Regel eine automatische Korrekturoption aktiviert.
• Tools: Möglicherweise verwendet ihr ein Build-Tool wie Nx. In diesem Fall benötigt ihr einen Link zur ESLint-Konfiguration für Nx-Monorepos, der im blauen Feld unten angezeigt wird.

Je nachdem, was ihr oben gewählt habt, findet ihr in den grünen und blauen Ressourcenfeldern unten Links zu Dokumentationen, in denen beschrieben wird, wie ihr ESLint mit eurem spezifischen Build-Tool oder Framework einrichten könnt.

• ESLint-Version: Ich empfehle, dem GPT die ESLint-Version zu berücksichtigen, wobei ich nur zwischen den Hauptversionen v8.x und v9.x unterscheide.
• Dateityp: Bisher wird JavaScript- und TypeScript-Linting unterstützt. JavaScript XML oder HTML werden nicht unterstützt. Daran wird derzeit gearbeitet, bevor es veröffentlicht wird.

Klickt einfach auf „Create Rule” (Regel erstellen), damit GPT eure Regel und einige fehlerhafte Beispielcodes erstellt, mit denen ihr eure neue Regel testen könnt. Mit „Lint Code” (Code überprüfen) könnt ihr den Beispielcode überprüfen und sehen, ob eure Regel wie beabsichtigt funktioniert. Falls ihr Lint-E gebeten habt, eine behebbare Fehlerquelle hinzuzufügen, könnt ihr diese mit „Apply Auto Fix” (Automatische Korrektur anwenden) testen. Danach könnt ihr natürlich erneut eine Lint-Prüfung durchführen und sehen, ob die angewendete Korrektur die Fehler beseitigt hat. Es kann nicht garantiert werden, dass sofort eine perfekte Regel und/oder behebbare Fehlerquelle erstellt wird. Die Code Editoren wurden offen gelassen, damit bei Bedarf manuelle Anpassungen vorgenommen werden können.

Warum das Spaß macht (und leistungsstark ist)

Mit unserer App benötigt ihr lediglich einen öffentlichen OpenAI-Schlüssel und eine benutzerdefinierte Regel. Ihr könnt:

• GPT auffordern, benutzerdefinierte Regeln zu generieren,
• die AST-basierte Logik der Regel anzeigen,
• sie in der Benutzeroberfläche live testen und validieren und
• die Regel innerhalb von Sekunden kopieren, exportieren und einbetten.

Es geht nicht nur um GenAI – es geht darum, GenAI als kreatives Werkzeug zu nutzen. Und wenn ihr das mit nützlichen Ideen, Wissen und Entwicklertools wie ESLint und ASTs kombiniert, sind die Möglichkeiten unglaublich!

Was kommt als Nächstes?

Ein Garten ohne Pflege ist ein Dschungel. Maßgeschneiderte Linting-Funktionen können dazu beitragen, dass euer Code-Garten wie gewünscht wächst. Möchtet uns dabei helfen, Lint-E für andere Frameworks oder sogar Sprachen zu unterstützen? Probiert es aus und gebt uns Feedback. Oder bringt einfach eure beste Idee für eine Lint-Regel mit und schaut, was GPT daraus macht.