Statische Analyseregeln mit Autokorrekturen schreiben, die das Laufzeitverhalten nicht ändern

## Häufige Muster abdecken und seltene Sonderfälle weglassen Halte jede Regel gedanklich einfach. Richte sie auf wiederkehrende, wertvolle Muster aus und unterstütze seltene Randfälle nicht, wenn deren Abdeckung die Regel verschleiern oder Korrekturen riskant machen würde. Lege mit einer Erstellungsfunktion und Metadaten einen stabilen Regelvertrag fest. Registriere in einem ereignisbasierten Adapter die Eintritts- und Austrittsempfänger über die bereitgestellten Einhängepunkte, statt eine herkömmliche Besuchszuordnung zurückzugeben. Die Empfänger sollen Problemobjekte zurückgeben oder mit yield liefern; die Berichterstattung übernimmt der Adapter. Jedes Problem soll den betreffenden Knoten und die Meldung angeben und Daten, eine Korrektur oder Vorschläge nur bei Bedarf ergänzen. Bietet die Korrektur-API einen Abbruchmechanismus, muss er immer verwendet werden, wenn sich eine sichere Bearbeitung nicht nachweisen lässt. Hinterlege voreingestellte Optionswerte in den Metadaten, damit das Rahmenwerk sie einheitlich zusammenführen kann, statt die Zusammenführungslogik in der Regel zu verdoppeln. ## Festlegen, in welche Voreinstellung die Regel kommt, und Optionsnamen mit check beginnen lassen Behandle die Zuordnung zu Voreinstellungen als Produktentscheidung: - Nimm unumstrittene Regeln in die sicherste Voreinstellung und in jede umfassendere Voreinstellung auf. - Nimm nützliche, aber meinungsgeprägte Standardwerte nur in die empfohlene Voreinstellung und in umfassendere Sammlungen auf. - Halte Nischenverhalten und ausdrücklich zu aktivierendes Verhalten aus den Standardvoreinstellungen heraus. Verwechsle „wertungsfrei“ nicht mit „zu meinungsstark“. Gib bei Unsicherheit die vorgeschlagene Stufe an und bitte die wartungsverantwortliche Person um eine Entscheidung. Benenne öffentliche boolesche Optionen positiv in der Form `check*`, damit `true` ein Verhalten stets aktiviert. Listen ignorierter Muster dürfen weiterhin übliche Namen wie `ignore` verwenden. Gib jede unterstützte Sprache ausdrücklich an. Hängt die Logik nur von Dateinamen, Rohtext, Kommentaren oder Anweisungen ab, unterstütze nach Möglichkeit mehrere Sprachen und verwende Stammknoten- und Kommentarhilfen, die sprachspezifische Knotentypen abstrahieren. ## Helfer nach ihrem Rückgabewert benennen und vorhandene Hilfsfunktionen wiederverwenden Benenne private Hilfsfunktionen nach ihrem beobachtbaren Vertrag. `is*`, `has*`, `should*`, `can*` und `needs*` müssen boolesche Werte zurückgeben, vorzugsweise ein ausdrückliches `false` statt eines versehentlichen undefined-Werts. Verwende `get*Problem` für ein optionales Problem und `get*Problems` für mehrere Probleme. Reserviere `report*` für Hilfsfunktionen, die unmittelbar berichten. Verbinde Berichterstattung oder yield nicht mit dem Ergebnis eines Prädikats. Erzeuge das Problem getrennt und triff die boolesche Entscheidung an der Aufrufstelle. Prüfe vor dem Hinzufügen einer Hilfsfunktion die AST-, allgemeinen Hilfs-, Korrektur- und gemeinsamen Regelmodule des Repositoriums und anschließend vertrauenswürdige Werkzeuge des Ökosystems. Verwende gebündelte Exporte und etablierte Hilfsfunktionen für statische Auswertung, Variablensuche, Seiteneffekterkennung, Tokenprüfungen, Referenzauflösung, Klammern, Semikolons und Korrekturaufbau wieder. Hebe eine Hilfsfunktion nur dann in einen gemeinsamen Bereich, wenn sie eindeutig wiederverwendbar ist; kleine regelspezifische Logik bleibt lokal. ## Kontrollflussanalyse nur nutzen, um zu prüfen, ob Code immer verlassen wird Verwende die Kontrollflussanalyse des Rahmenwerks, wenn eine Regel feststellen muss, ob ein Zweig oder eine Funktion über Konstrukte wie return, throw, break, continue, eine vollständige Auswahl oder eine Endlosschleife immer beendet wird. Das manuelle Durchlaufen des AST ist bei Ausnahmebehandlung, Sprungmarken, Verschachtelung und unerreichbaren Abschnitten meist ungenauer. Registriere für die Zweiganalyse den Zweigabschlussverfolger des Repositoriums und frage ihn ab, nachdem die umgebende Bedingung verlassen wurde. Verwalte für die Funktionsanalyse je Programmpfad eine Segmentmenge, damit verschachtelte Funktionen ihre Eltern nicht beeinflussen. Erfasse die Erreichbarkeit beim Verlassen des betreffenden AST-Knotens; warte nicht bis zum Ende des Programmpfads, wenn das Rahmenwerk die aktuellen Segmente bereits geleert hat. Verwende einfachere Syntaxprüfungen, wenn nur gefragt ist, ob die letzte Anweisung einen bestimmten Typ hat, wo return vorkommt oder ob ein lokales Korrekturmodul mit return oder throw endet. Führe ohne tatsächlichen Bedarf an einer Erreichbarkeitsprüfung keine Kontrollflussmechanik ein. ## Erzeugte Indizes und Dokumentationsköpfe neu erzeugen statt von Hand ändern Bestimme automatisch erzeugte Dateien und Bereiche vor der Bearbeitung. Bearbeite automatisch erzeugte Indizes, Tabellen oder Dokumentationsüberschriften niemals von Hand. Führe nach dem Hinzufügen, Entfernen oder Umbenennen von Quellregeln den zuständigen Generator aus. Bewahre bei der Konfliktauflösung die maßgeblichen Einträge und erzeuge deterministische Ergebnisse neu, statt sie von Hand nachzubauen. Platziere von Menschen verfasste Dokumentation unterhalb jeder Grenze einer automatisch erzeugten Überschrift. Verwende in Beispielen die vom Repositorium bevorzugte Konfigurationssyntax; wechsle nur dann zu JSON-ähnlichen Beispielen mit Anführungszeichen, wenn das Beispiel ausdrücklich JSON ist. Wenn gemeinsame Regelmuster auch in einem verwandten Repositorium oder Paket vorhanden sind, prüfe, ob dieselbe Änderung übertragen werden soll. Behandle dies als ausdrückliche Kompatibilitätsentscheidung und nicht als automatische projektübergreifende Bearbeitung. ## Beim Entwickeln nur die Tests der Regel und am Ende die ganze Suite ausführen Schreibe vor oder während der Umsetzung zielgerichtete Tests. Bevorzuge Momentaufnahmetests, wenn die Testumgebung Diagnosen, Korrekturen und Vorschläge gemeinsam erfassen kann, und verwende besondere Parsermodi nur für Fälle, die sie benötigen. Führe während der Entwicklung nur den Test der betreffenden Regel aus. Aktualisiere Momentaufnahmen bewusst und entferne vor dem Abschluss vorübergehende Fokusmarkierungen für Tests. Führe langsame Integrationstests nicht im üblichen Bearbeitungszyklus aus. Führe nach der Umsetzung einer neuen Regel und nach jeder Logikkorrektur einen Eigenanwendungstest durch, weil Korrekturen häufig Verstöße an anderen Stellen sichtbar machen. Führe am Ende das tatsächliche Prüfwerkzeug des Repositoriums, die zielgerichteten Tests und den Eigenanwendungstest aus und danach genau einmal den vollständigen Testsatz. Ersetze das vorgesehene Prüfwerkzeug nicht nur deshalb durch ein anderes, weil dieses keine Fehler meldet. ## Korrekturen mit Kommentaren und heikler Syntax testen Teste Verhalten, Nichttreffer, Korrekturen und Vorschläge, ohne Abdeckung zu verdoppeln. Nimm zutreffende Fälle aus diesen Gruppen auf: - typisierte Syntax, Typzusicherungen, Generika und optionale Verkettung; - JSX, Kommentare, zusätzliche Klammern sowie verschachtelte und verkettete Ausdrücke; - berechnete Eigenschaften, Vorlagen, Spread-Syntax und Destrukturierung; - verwendete gegenüber nicht verwendeten Rückgabewerten; - reine Syntaxanalyse gegenüber vollständigen Typinformationen, wenn die Regel von Typen abhängt. Teste die Fälle, die eine Regel absichtlich ignoriert, damit die Grenze dokumentiert ist. Prüfe Korrekturen bei Kommentaren und bei Gefahren durch automatische Semikoloneinfügung. Benötigt ein Fall einen anderen Parser, richte ihn im kleinsten Testumfang ein, der die Anforderung ausdrückt. ## Autokorrektur nur anbieten, wenn sie das Laufzeitverhalten nicht ändert, und Kommentare erhalten Biete eine automatische Korrektur nur an, wenn sie das Laufzeitverhalten nicht verändern kann. Könnte sich das Verhalten ändern, bevorzuge einen Vorschlag. Die Erhaltung von Kommentaren ist verbindlich: Enthält ein Ersatz oder ein zu entfernender Bereich Kommentare, brich die Korrektur ab oder verwende eine bereichsbezogene Bearbeitung, die sie an ihrer Stelle belässt. Prüfe vor dem Erzeugen einer Korrektur, ob ein Ersatz Klammern benötigt, ob eine führende eckige oder runde Klammer ein Semikolon erfordert und ob benachbarte Tokens Abstand benötigen. Verwende Generatorkorrekturen für Vorgänge mit mehreren Bearbeitungen. Bewahre das Verhalten optionaler Verkettungen und vermeide unsichere Bearbeitungen, wenn ein Wert anders als ein eigenständiger Ausdruck verwendet wird. Gestalte Korrekturen nicht unverhältnismäßig komplex, nur um verdeckte eingebaute Bezeichner, Seiteneffekte von Zugriffsfunktionen oder Proxys oder Lücken in dünn besetzten Arrays zu erhalten, sofern das Repositorium nicht bereits eine einfache lokale Schutzmaßnahme besitzt. Melde das Problem ohne Korrektur, wenn sich die Sicherheit nicht belegen lässt. ## Die Regel benennen, aus dem Gerüst anlegen und von den Tests bis zum Commit bringen Wähle Namen, die Konstrukt und Absicht beschreiben: Verwende Präfixe wie `no-`, `prefer-`, `require-` oder `consistent-`, wenn sie das Verhalten verdeutlichen. Benenne das Ziel und nicht den vorgeschlagenen Ersatz und vermeide unklare Namen. Verwende das Projektgerüst des Repositoriums, um Umsetzung, Test, Dokumentation und automatisch erzeugte Indexeinträge anzulegen. Befolge anschließend diese Reihenfolge: 1. Füge fehlschlagende oder repräsentative Tests hinzu. 2. Setze die kleinste Regellogik um, die diese Tests erfüllt. 3. Dokumentiere das Verhalten und absichtliche Ausschlüsse. 4. Führe zielgerichtete Tests und den maßgeblichen Prüfbefehl aus. 5. Führe den Eigenanwendungstest und am Ende den vollständigen Testsatz aus. 6. Bestätige, dass automatisch erzeugte Dateien aktuell und vorübergehende Hilfsdateien entfernt sind. Verwende die Konvention des Projekts für Commit-Nachrichten einschließlich der vorgeschriebenen Satzzeichen um Regel- und Optionsnamen. Die Auslieferung ist erst abgeschlossen, wenn Quelltext, Tests, Dokumentation, automatisch erzeugte Bereiche und Prüfungsergebnisse übereinstimmen.