Zusammenfassung

Dieses kostenlose KI Code Review Tool ist ein regelbasierter Vorab-Check. Sie fügen einen Git-Diff oder ein Snippet ein, dann prüft es die hinzugefügten Zeilen anhand von dreizehn Regeln zu fest codierten Secrets, per String gebauter SQL, verschluckten Exceptions und vergessenen Tests oder Debug-Resten. Zusätzlich markiert es zu große Änderungen und fehlende Tests und gibt einen Score von 0 bis 100 mit nummerierten Befunden aus. Alles läuft im Browser, ohne KI-Modell, und soll die mechanischen Punkte klären, bevor ein Mensch reviewt.

Prüfen Sie Ihren Diff, bevor es der Reviewer tut

Fügen Sie einen Git-Diff oder ein Snippet ein. Dieses kostenlose KI Code Review Tool findet im Browser Secrets, unsichere SQL, verschluckte Fehler, Debug-Reste und zu große Änderungen und vergibt einen Score von 100 für den Pull Request.

Meinen Diff prüfen
Ingenieur prüft einen Side-by-Side-Vergleich von Code-Änderungen auf einem Monitor

Prüfer für Diffs vor dem Review

Fügen Sie einen Unified Diff oder beliebigen Code ein. Erkennt das Tool einen Diff, werden nur hinzugefügte Zeilen geprüft. Was Sie einfügen, verlässt Ihren Browser nicht.

--/100
Code einfügen, um zu starten
Noch nichts geprüft.
    So funktioniert es

    Was der Prüfer anschaut und was er ignoriert

    Nur hinzugefügte Zeilen

    Fügen Sie einen Unified Diff ein, liest der Prüfer die Hunk-Header, zählt die Zeilennummern der neuen Datei und durchsucht nur die Zeilen, die Sie hinzugefügt haben. Entfernte Zeilen und unveränderter Kontext erzeugen nie einen Befund. Alter Code wird Ihnen so nicht angelastet.

    Nach Schwere gewichteter Score

    Dreizehn Regeln sind in drei Stufen eingeteilt. Hoch kostet 15 Punkte: fest codierte Secrets, eval, per String gebaute SQL, deaktivierte TLS-Prüfungen. Mittel kostet 7: verschluckte Exceptions, fokussierte Tests, innerHTML, ein Diff mit mehr als 400 Zeilen. Niedrig kostet 2: TODOs, Debug-Ausgaben, auskommentierter Code. Jede Regel zählt höchstens dreimal.

    Größen- und Testprüfung

    Ab 200 hinzugefügten Zeilen erhalten Sie den Hinweis, die Änderung aufzuteilen, ab 400 einen deutlicheren. Das folgt der Studie von SmartBear zu Cisco, nach der die Review-Qualität sinkt, sobald ein Reviewer mehr als 200 bis 400 Zeilen auf einmal vor sich hat. Ein Diff mit mehr als 50 hinzugefügten Zeilen ohne Testdatei wird ebenfalls markiert.

    Anwendung

    Vom Einfügen bis zum sauberen Pull Request in vier Schritten

    1. 1

      Diff einfügen

      Führen Sie git diff main...HEAD oder git diff --staged vor dem Commit aus und fügen Sie die Ausgabe ein. Ein einfaches Snippet funktioniert auch, aber Dateinamen und die Erkennung von Testdateien gehen verloren.

    2. 2

      Zuerst die hohen Befunde lesen

      Rote Einträge sind die Stellen, an denen ein Reviewer stehen bleibt. Ein fest codierter Schlüssel bleibt nach dem Löschen der Zeile in der Historie erhalten. Rotieren Sie ihn, statt ihn nur zu entfernen.

    3. 3

      Den Rest korrigieren oder begründen

      Jeder Befund enthält eine Korrektur in einer Zeile. Ist ein Hinweis ein Fehlalarm, nennen Sie das in der PR-Beschreibung. Das erspart dem Reviewer dieselbe Rückfrage.

    4. 4

      Checkliste kopieren

      Mit dem Kopieren-Button werden die Befunde zu einer Markdown-Checkliste, die Sie in den PR-Text einfügen können. Der Reviewer sieht so, was Sie bereits abgefangen haben.

    Warum ein Vorab-Check

    Die ersten dreißig Sekunden eines Reviews sollten nicht für console.log draufgehen

    Eine Pull-Request-Anfrage von einem Kollegen kennen Sie. Sie scrollen durch den Diff und entdecken eine vergessene Debug-Ausgabe, ein TODO ohne Ticket, einen übersprungenen Test und einen catch-Block, der den Fehler verschluckt. Dafür braucht es keinen Menschen. Es braucht eine Checkliste, die läuft, bevor die Anfrage rausgeht. Genau diese Lücke schließt das Tool. Die Aufmerksamkeit eines Reviewers ist begrenzt: Laut der Studie von SmartBear zu Cisco-Reviews hält die Fehlererkennung, wenn Menschen 200 bis 400 Zeilen in 60 bis 90 Minuten prüfen, und lässt danach nach. Jede Minute für mechanische Befunde fehlt bei den Fragen, die nur ein Mensch beantworten kann: Ist das der richtige Ansatz, passt es zur Architektur, wird es in sechs Monaten noch Sinn ergeben? Es ersetzt keinen Reviewer und tut auch nicht so. Es entfernt die billigen Einwände, damit das menschliche Review beim interessanten Teil beginnt.

    • Fängt die mechanischen Befunde ab, bevor die Review-Anfrage rausgeht
    • Gibt jedem Befund eine Zeilennummer aus den Hunk-Headern des Diffs
    • Läuft lokal, daher sicher für proprietären Code
    Zwei Ingenieure besprechen eine Code-Änderung an einem Laptop
    FAQ

    Fragen zum Prüfer

    Ist das ein KI-Code-Reviewer oder ein Linter?
    Genau genommen keines von beidem. Es ist ein regelbasierter Vorab-Check. Kein Modell liest Ihren Code, und es wird nichts generiert. Dreizehn Musterregeln prüfen die hinzugefügten Zeilen auf das, was ein Reviewer in den ersten dreißig Sekunden markiert: Secrets, per String gebaute SQL, verschluckte Exceptions, vergessene Debug-Ausgaben. Wir benennen das ehrlich, denn ein KI-Reviewer, der rät, ist schlechter als eine Checkliste, die nur Muster findet.
    Verlässt mein Code den Browser?
    Nein. Die Prüfungen laufen in JavaScript auf dieser Seite. Es gibt keinen Upload, keinen API-Aufruf und kein Konto. Erfasst wird nur ein anonymes Ereignis, dass das Tool benutzt wurde, ohne Inhalt aus dem Textfeld.
    Woher stammen die Regeln für 200 bis 400 Zeilen und für Testdateien?
    Die Größenschwelle folgt der Studie von SmartBear zu Cisco-Review-Daten, die empfiehlt, nicht mehr als 200 bis 400 Zeilen auf einmal zu prüfen. Die Regel für kleine Änderungen folgt den öffentlichen Engineering-Praktiken von Google zu kleinen CLs. Die Testregel ist unsere Konvention: Ein Diff mit mehr als 50 hinzugefügten Zeilen ohne Testdatei wird markiert, weil Reviewer diese Frage ohnehin stellen.
    Wie wird der Score berechnet?
    Er beginnt bei 100. Jeder Befund zieht Punkte nach Schwere ab: 15 für hoch, 7 für mittel, 2 für niedrig. Jede Regel zählt höchstens dreimal, sodass eine störende Regel den Score nicht auf null drücken kann. Es ist eine Konvention, um Arbeit zu priorisieren, kein Maß für Codequalität. Ein Score von 100 heißt nur, dass keine Regel angeschlagen hat, nicht dass der Code korrekt ist.
    Was übersieht es?
    Alles, was Verständnis verlangt: falsche Geschäftslogik, Race Conditions, eine schlechte Abstraktion, eine API, die schlecht altert. Musterbasierte Regeln liefern auch Fehlalarme, zum Beispiel wenn eine Testfixture ein Fake-Passwort enthält. Behandeln Sie jeden Befund als Frage, die Sie beantworten sollten, nicht als Urteil.
    Mit welchen Sprachen funktioniert es?
    Die Regeln sind Textmuster und funktionieren daher mit JavaScript, TypeScript, Python, Java, Go und den meisten Sprachen der C-Familie. Einige Regeln sind sprachspezifisch: nacktes except ist Python, System.out.println ist Java, InsecureSkipVerify ist Go. Fügen Sie einen Unified Git-Diff ein, dann stammen die Zeilennummern aus den Hunk-Headern.
    Ist es kostenlos?
    Ja, ohne Anmeldung. Wenn Sie während des Reviews Antworten zum Rest Ihres Repositorys brauchen, etwa wer diese Funktion aufruft oder wo ein Konfigurationswert gelesen wird, dafür ist codebasechat da.

    Reviewen Sie mit dem gesamten Repository im Blick

    Ein Diff zeigt, was sich geändert hat, nicht, was davon abhängt. codebasechat beantwortet Fragen zu Ihrer Codebasis in einfacher Sprache, damit Sie prüfen können, wer die geänderte Funktion aufruft, bevor Sie freigeben.

    codebasechat kostenlos testen