Die Schlampigkeit von Code messen: Metriken für Weitschweifigkeit und Erosion

LLMs sind inzwischen sehr gut darin, Code zu generieren, der Tests besteht. Aber korrekter Code kann trotzdem schlampig sein: voller duplizierter Zeilen, unnötiger Abstraktionen und schlechter Designentscheidungen. Wie der Autor anmerkt: "Nur weil der Code formal korrekt ist, heißt das nicht, dass er keine unnötigen Abstraktionen einführt, Duplikate erzeugt oder insgesamt einfach schlechte Entscheidungen trifft." Das Ergebnis ist eine Explosion der Codezeilen (LOC), mit der Menschen kaum Schritt halten können, und – entgegen manchen Behauptungen – auch Agenten können den Schlamm nicht bewältigen.

Warum LLM-as-Judge nicht funktioniert

Der Artikel verwirft den gängigen Branchenansatz, KI zur Bewertung der Codequalität einzusetzen. Ein Modell zu bitten, Code auf einer Skala von 1–10 zu bewerten, ist "im Grunde gleichbedeutend mit einem Zufallszahlengenerator". Paarweise Vergleiche (A vs. B) sind instabil: Schon das Umbenennen der Lösungen kann die Präferenz des Modells umkehren. Rubriken und von LLMs geschriebene Tests helfen, sind aber "noch weit davon entfernt, den Schlamm tatsächlich loszuwerden".

Die einfachste Metrik: Änderung der LOC

Überraschend effektiv: einfach die Veränderung der Anzahl der Codezeilen verfolgen. Der Autor bemerkt die Ironie: "Wenn wir anfangen würden, darauf zu optimieren, würde es aufhören, ein aussagekräftiges Maß zu sein."

Verbosity

Misst duplizierte und unnötig verbose Zeilen. Es ist der Anteil der Zeilen, die von AST-Grep markiert oder als Klone gekennzeichnet wurden, geteilt durch die gesamten LOC:

Verbosity = |AST-Grep flagged lines ∪ clone lines| / LOC

Erosion

Misst, wie viel der Masse einer Codebasis in wenigen großen, komplexen Funktionen konzentriert ist. Zuerst wird die Masse einer Funktion definiert:

mass(f) = CC(f) * sqrt(SLOC(f))

Wobei CC(f) die zyklomatische Komplexität und SLOC(f) die Quellcodezeilen sind. Dann ist Erosion der Anteil der Gesamtmasse, der auf Funktionen mit einer zyklomatischen Komplexität größer als 10 entfällt:

Erosion = ∑_{f: CC(f) > 10} mass(f) / ∑_f mass(f)

Diese beiden Maße – eingeführt durch das Paper SlopCodeBench – trennten in den Tests des Autors Legacy-Codebasen recht gut von LLM-generiertem Schlamm.

Erkenntnisse

• LLM-Judges sind unzuverlässig für Codequalität; Präferenzen kippen beim Umbenennen.
• Die Änderung der LOC ist ein überraschend starkes Signal für Schlampigkeit, bricht aber, wenn direkt darauf optimiert wird.
• Verbosity kombiniert AST-Grep-Markierungen und Klonerkennung über LOC.
• Erosion erfasst Komplexitätsmasse in Funktionen mit CC > 10.

Für Teams, die LLM-generierten Code in großem Umfang ausliefern, bieten diese Metriken eine quantitative Alternative zur Bewertung nach Bauchgefühl.