Zeilenzähler

Dieser Zeilenzähler zerlegt jeden eingefügten Text oder Quellcode in Gesamtzeilen, Leerzeilen, Kommentarzeilen und echte Codezeilen, zusammen mit der maximalen und der durchschnittlichen Zeilenlänge. Er ist nützlich für Entwickler, die eine Datei einschätzen wollen, für Autoren, die die Dokumentstruktur prüfen, und für alle, die mehr Detail brauchen als ein einfacher Wortzähler liefert. Alles aktualisiert sich beim Tippen und bleibt auf Ihrem Rechner.

Wie jede Kennzahl berechnet wird

Kennzahl	Definition
Gesamtzeilen	Zeilen nach Normalisierung der Zeilenenden und Entfernen eines abschließenden Umbruchs
Nicht leere Zeilen	Zeilen mit mindestens einem Zeichen nach dem Trimmen (wenn Trimmen aktiv ist)
Leerzeilen	Gesamtzeilen minus nicht leere Zeilen
Kommentarzeilen	Zeilen, deren erste Nicht-Leerzeichen einem Kommentarmarker entsprechen
Codezeilen	Nicht leere Zeilen minus Kommentarzeilen
Maximale / durchschnittliche Zeilenlänge	Über nicht leere Zeilen berechnet, nach Trimmen, falls aktiviert

Weil Code-, Kommentar- und Leerzeilen aus derselben Nicht-leer-Zählung abgeleitet werden, summieren sie sich immer wieder zur Gesamtsumme — es gibt keine Doppelzählung.

Praxisbeispiel: eine kurze Python-Datei

Fügen Sie dieses neunzeilige Snippet ein, mit Trimmen und Kommentarerkennung beide aktiv:

import math

# circle area
def area(r):
    return math.pi * r * r

# --- test ---
if __name__ == "__main__":
    print(area(2))

Die Statistik-Tabelle meldet:

• Gesamtzeilen: 9
• Nicht leer: 7 (die Leerzeilen 2 und 6 sind ausgeschlossen)
• Leer: 2
• Kommentar: 2 (# circle area und # --- test ---)
• Code: 5
• Maximale Zeilenlänge: 26 (if __name__ == "__main__":)
• Durchschnittliche Zeilenlänge: 16,0

Aktivieren Sie Trimmen von Leerzeichen, wird die eingerückte return-Zeile ohne ihre vier führenden Leerzeichen gemessen, weshalb der Durchschnitt bei 16,0 statt höher landet.

Kommentarregeln und was sie übersehen

Das ist bewusst eine schnelle Zeilenpräfix-Heuristik, kein Parser. Dadurch ist sie ohne Konfiguration über Sprachen hinweg nützlich, hat aber bekannte blinde Flecken:

• Nur der Zeilenanfang wird geprüft. x = 1; // set x ist Code, ebenso ein /* ... */-Block, dessen öffnende Klammer mitten in der Zeile steht.
• C-Präprozessoranweisungen schlagen fehl. #include <stdio.h> beginnt mit # und wird als Kommentar gezählt, obwohl es Code ist.
• Zeigerarithmetik schlägt fehl. Eine C-Zeile, die mit *ptr = 5; beginnt, passt zur *-Kommentarregel und wird als Kommentar gezählt, während */-Abschlüsse nicht erkannt werden.
• Shell-Flags können fehlschlagen. Eine Zeile, die mit --verbose beginnt, wird als Kommentar gezählt, weil -- der SQL/Lua-Marker ist.
• Blockkommentare werden nicht über Zeilen hinweg verfolgt. Nur die markertragenden Zeilen werden gezählt; ein mehrzeiliger Block trägt so viele Kommentarzeilen bei, wie er Markerzeilen hat, nicht wie viele er umspannt.

Betrachten Sie die Zählung als Signal, nicht als Prüfung. Ein statischer Analysator ist für eine bestimmte Sprache immer präziser.

Zeilenenden und der Randfall am Dateiende

Dateien von Windows kommen mit CRLF-Endungen, Dateien von klassischen Macs mit nacktem CR, Unix-Werkzeuge mit LF. Der Zähler normalisiert alle drei zuerst zu LF, die Zeilenzählungen stimmen also über Quellen hinweg überein. Dann entfernt er genau einen abschließenden Umbruch: "a\nb\n" zählt als 2 Zeilen, nicht als 3, während "a\nb\n\n" als 3 mit einer Leerzeile zählt. Bei leerer Eingabe werden lauter Nullen statt eines Fehlers zurückgegeben. Deaktivieren Sie das Trimmen, ist eine Zeile aus reinen Leerzeichen nicht mehr leer und geht mit ihrer Auffüllung in die Längenstatistik ein.

Was Zeilenzahlen verraten — und was nicht

Zeilen Quellcode ist eine der ältesten Software-Kennzahlen und eine der am meisten missbrauchten. Rohe Summen beschreiben Größe, nicht Qualität: Eine knappe, elegante Funktion und eine aufgeblähte können dieselbe Aufgabe mit sehr unterschiedlichen Zahlen erledigen, und LOC zur Bewertung von Entwicklerproduktivität zu nutzen, belohnt bekanntermaßen Geschwätzigkeit und bestraft das Refactoring, das Zeilen entfernt.

Ihren Platz verdient die Aufschlüsselung bei der Charakterisierung einer Codebasis. Ein hoher Kommentaranteil signalisiert meist gut dokumentierten Code — oder veraltete Kommentare. Eine lange maximale Zeile markiert oft Formatierungsschulden. Ein unerwarteter Sprung beim Leerzeilenanteil kann generierte oder maschinell zusammengeführte Ausgabe verraten. Für Prosa und Daten beantworten dieselben Zahlen praktische Fragen: Hat dieses Log leere Zeilen, ist mein Datensatz ein Datensatz pro Zeile, wie konsistent sind meine Zeilenlängen? Dieses Tool liefert diese Signale sofort, ohne eine statische Analysesuite einzurichten.

Praktische Tipps

• Vergleichen Sie eine Datei vor und nach einem Refactoring. Fügen Sie die alte Version ein, notieren Sie Code- und Kommentarzeilen, dann fügen Sie die neue ein. Weniger Codezeilen bei gleicher Kommentarzahl bedeuten meist eine echte Vereinfachung; ein Rückgang der Kommentarzeilen ist eine Warnung, kein Gewinn.
• Erzwingen Sie eine Spaltengrenze. Begrenzt Ihr Projekt Zeilen auf 80 oder 100 Zeichen, zeigt die maximale Zeilenlänge sofort, ob etwas die Regel bricht, und der Durchschnitt verrät, wie viel Spielraum der Rest der Datei hat.
• Prüfen Sie Daten und Logs am Leerzeilenanteil. Eine wohligeformte CSV sollte null Leerzeilen enthalten, während ein in Blöcken exportiertes Log oft leere Trennzeilen bildet. Ein unerwarteter Leerzeilenanteil erwischt einen fehlerhaften Export, bevor er eine Datenbank erreicht.
• Vergleichen Sie nie Sprachen oder Personen anhand von Codezeilen. Python drückt in zehn Zeilen aus, wofür Java dreißig braucht. Nutzen Sie die Zählung, um eine Datei oder ein Projekt über die Zeit zu verfolgen, nicht um Sprachen oder Entwickler zu bewerten.

Verwandte Tools

• Wortzähler — Wörter, Zeichen, Sätze und Lesezeit zählen.
• Textstatistik — eine breitere Aufschlüsselung eingefügten Texts.
• Diff Checker — zwei Versionen Zeile für Zeile vergleichen.