boyter/scc: Der Go-Codezähler mit Komplexität, COCOMO und LOCOMO
Sloc, Cloc und Code: scc ist ein sehr schneller, genauer Codezähler mit Komplexitätsberechnungen und COCOMO-Schätzungen, geschrieben in reinem Go.
Auf einen Blick
- Was ist das?
- Eine Rezension des Kommandozeilenwerkzeugs scc: Zeilenzählung in vielen Sprachen, Komplexitätsnäherung, ULOC- und DRYness-Metriken, Git-Insight-Berichte und ein experimenteller LLM-Kostenschätzer.
- Für wen ist es gedacht?
- scc eignet sich für Entwickler und Teams, die eine schnelle, reproduzierbare Codezählung mit Komplexitäts- und Kostenindikatoren wollen, etwa in CI-Skripten oder vor Migrationen. Weniger geeignet ist es, wer exakte zyklomatische Komplexität oder vertragsreife Kostenschätzungen braucht; beides liefert scc nur als Näherung.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Sloc Cloc and Code: was scc zählt und warum es in Go entstanden ist
scc, ausgeschrieben Sloc Cloc and Code, ist ein Kommandozeilenwerkzeug, das Codezeilen, Leerzeilen, Kommentarzeilen und physische Zeilen in vielen Programmiersprachen zählt. Es steht in der Tradition von cloc, sloccount und tokei, ist aber in reinem Go geschrieben und verfolgt das erklärte Ziel, der schnellste Codezähler zu sein. Zusätzlich soll es COCOMO-Kalkulationen wie sloccount liefern, LOCOMO-Schätzungen für Entwicklungskosten mit großen Sprachmodellen, eine Komplexitätsnäherung nach Art zyklomatischer Rechner sowie Metriken für eindeutige Codezeilen und DRYness.
Das Werkzeug treibt laut README die Suche searchcode.com an und wird unter der MIT-Lizenz vertrieben. Mit rund 8.700 Sternen auf GitHub und frischen Releases wie v4.0.0 vom August 2026 zeigt sich eine gepflegte Codebasis; daneben kündigt der Autor eine scc Enterprise für Teams mit Verlaufsanalyse und Richtlinienprüfung an, für die derzeit eine Interessentenliste für eine private Beta geführt wird.
Installation über go install, brew und den Docker-Lauf ohne Netzwerk
Die Installation läuft über die Go-Toolchain mit go install github.com/boyter/scc/v4@latest, wofür Go in Version 1.25 oder höher nötig ist; die Entwicklungsversion folgt dem Suffix @master. Daneben bietet das README Snap mit sudo snap install scc, Homebrew mit brew install scc, das Fedora-COPR-Repository lihaohong/scc via sudo dnf copr enable lihaohong/scc && sudo dnf install scc, MacPorts mit sudo port install scc sowie Scoop, Chocolatey und WinGet für Windows, wobei WinGet über die ID benboyter.scc installiert. Auf FreeBSD genügt pkg install scc.
Ein bemerkenswerter Weg ist der Docker-Lauf: docker run --rm -it -v "$PWD:/pwd:ro" --network none ghcr.io/boyter/scc:master scc /pwd bindet das aktuelle Verzeichnis nur lesbar ein und trennt das Netzwerk komplett. Fertige Binärdateien für Windows, GNU/Linux und macOS stehen auf der Releases-Seite bereit. Beim Snap-Weg warnt das README, dass Snap-Anwendungen außerhalb von /home auf Probleme stoßen können.
Komplexität als Näherung: scc --by-file -s complexity richtig lesen
Die Komplexitätszahl entsteht nicht aus einem Syntaxbaum. scc sucht während des Scans nach Verzweigungs- und Schleifenanweisungen wie for, if, switch, while, else sowie den Operatoren ||, &&, != und == und erhöht pro Treffer einen Dateizähler. Das Ergebnis ist eine Näherung an die zyklomatische Komplexität, keine exakte Berechnung. Daraus folgt eine Leseregel aus dem README: Die Zahl eignet sich nur zum Vergleich von Dateien derselben Sprache, denn Sprachen, die Rekursion statt Schleifen verwenden, schneiden in dieser Zählung anders ab.
Praktisch lässt sich die stärkste Datei eines Projekts mit scc --by-file -s complexity finden. Für Reviews ist das ein schneller Filter, um zu klären, welche Datei ein zweites Paar Augen verdient. Wer exakte Zahlen braucht, muss auf echte AST-Werkzeuge ausweichen; für die relative Sortierung innerhalb einer Sprache genügt die billige Suche laut Projektangabe.
ULOC und DRYness: Duplikate in der Zählung von scc sichtbar machen
ULOC, die Unique Lines of Code, zählt eindeutige Zeilen über Sprachen, Dateien und das Projekt hinweg. Die Idee stammt aus einem Artikel auf cmcenroe.me und lässt sich klassisch mit sort -u *.h *.c | wc -l nachbilden. Der Wert korrigiert SLOC um Leerzeilen und wiederkehrende Strukturen wie schließende Klammern, während Kommentare mitgezählt werden und Lizenzköpfe, die in jeder Datei wiederkehren, das Ergebnis nicht aufblähen.
Aktiviert wird ULOC mit -u oder --uloc, der DRYness-Anteil, also ULOC geteilt durch SLOC, mit -a oder --dryness; eine höhere Zahl bedeutet weniger duplizierten Code. Das README warnt, dass die ULOC-Berechnung die Laufzeit verdoppeln kann. Für Codebasen mit vielen generierten Dateien ist der Wert ein realistischerer Umfangsindikator als die bloße Zeilenzahl, weil Wiederholung sichtbar wird, statt unsichtbar in der Summe zu verschwinden.
COCOMO und LOCOMO: Personalkosten gegen LLM-Kosten abschätzen
Jeder Lauf zeigt COCOMO-Schätzungen an: Aufwand, geschätzte Kosten und benötigte Personen. Das Modell lässt sich über organic, semi-detached oder embedded wählen oder mit eigenen Parametern überschreiben, etwa --cocomo-project-type "custom,1,1,1,1". COCOMO schätzt menschliche Erstellungskosten und stammt aus einer Zeit, in der die Zeilenzahl als Kostentreiber galt.
LOCOMO, das LLM Output COst MOdel, geht einen anderen Weg: Es ist ein experimenteller, ausdrücklich nicht-industrieller Schätzer dafür, was es kosten würde, eine Codebasis mit einem großen Sprachmodell neu zu erzeugen. Es ist Opt-in, angezeigt wird es über --locomo, beides zusammen über --cost-comparison. Voreinstellungen für Modellklassen large, medium, small und local existieren, und Preise, Durchsatz sowie Prüfzeit lassen sich überschreiben. Für Budgetfragen bei LLM-basierter Wartung liefert das eine diskutable Größenordnung, aber keine Zahl, die man als Vertragsgrundlage nehmen sollte; der Autor selbst stuft das Modell als experimentell ein.
Git-Insight-Berichte in scc: hotspots, coupling und timeline
Das README beschreibt fünf git-bewusste Berichte, die per Flag einschaltbar sind: --hotspots für komplexe Dateien mit hoher Änderungsrate, --coupling für Dateipaare, die sich gemeinsam ändern, --coupling-for für den Explosionsradius einer bestimmten Datei, --by-author für die Zuordnung des letzten Bearbeiters und --timeline für eine Verlaufsansicht. Diese Berichte sind deutlich langsamer als ein normaler Lauf, weil sie die Repository-Historie durchwandern und pro Commit einen Diff rechnen, mit einem reinen Go-Myers-Diff, ohne das git-Binärprogramm aufzurufen.
Die Tiefe steuert das Flag --depth, das standardmäßig 1.000 Commits umfasst und mit 0 die gesamte Historie durchläuft. Für Teams, die technische Schuld lokalisieren wollen, sind Hotspots und Coupling die aussagekräftigsten Berichte, weil sie Wartungsaufwand dort vermuten lassen, wo Komplexität und Änderungsfrequenz zusammentreffen. Neben scc listet das README konkurrierende Zähler wie tokei, cloc, gocloc, loc und loccount, wer nur eine schnelle Zahl braucht, kann mehrere davon direkt vergleichen.
Redaktionelles Fazit
scc eignet sich für Entwickler und Teams, die eine schnelle, reproduzierbare Codezählung mit Komplexitäts- und Kostenindikatoren wollen, etwa in CI-Skripten oder vor Migrationen. Weniger geeignet ist es, wer exakte zyklomatische Komplexität oder vertragsreife Kostenschätzungen braucht; beides liefert scc nur als Näherung. Zuerst sollte man die Berichte --hotspots und --coupling gegen eine kleine Beispielhistorie laufen lassen und prüfen, ob der Standardwert von --depth 1000 für das eigene Repository die gewünschte Aussagekraft liefert.
Community-Notizen