Lines of Code

White_Fox

Top Contributor
Erreiche ich bei der Programmierung eine gewisse Komplexität der Programmarchitektur, stellt mir irgendwas ein Bein und ich stürze.
Profitipp: Dann halte das Programm einfach.

Ja - klar klingt das blöd, aber letztlich ist das genau die Lösung. Jeder, wirklich jeder hier, stößt irgendwann an seine Grenzen. Ich persönlich habe ein Limit bei 1.000 Codezeilen. Ich habe zwar bei 500 Codezeilen schon Bauchweh, aber 1.000 Codezeilen pro Datei sind so meine persönliche Schmerzgrenze. Wird die überschritten sehe ich bei der nächsten Refaktur zu, daß es weniger wird.

Die Kunst ist, ein großes Problem in viele kleine Teilprobleme zu zerlegen. Und sich NICHT einen darauf runterholen, wie krass komplizierten Code man doch heute wieder geschrieben hat. Die wahre Kunst liegt in der Einfachheit. Code schreiben, den niemand leicht durchblickt (einschließlich des Zukunftautors) kann jeder. Aber Code schreiben, den jeder sofort lesen und verstehen kann, das ist tatsächlich schwerer, manchmal sogar richtig schwierig. Da gehen durchaus mal zehn Minuten dafür drauf, sich einen vernünftigen Namen für eine Variable auszudenken: drei Minuten beim ersten Deklarieren, die restlichen sieben Minuten während verschiedener Refakturen während man die Methode schreibt. Klassen- und Methodennamen dito.
 
Zuletzt bearbeitet von einem Moderator:
K

kneitzel

Gast
Ja - klar klingt das blöd, aber letztlich ist das genau die Lösung. Jeder, wirklich jeder hier, stößt irgendwann an seine Grenzen. Ich persönlich habe ein Limit bei 1.000 Codezeilen. Ich habe zwar bei 500 Codezeilen schon Bauchweh, aber 1.000 Codezeilen pro Datei sind so meine persönliche Schmerzgrenze. Wird die überschritten sehe ich bei der nächsten Refaktur zu, daß es weniger wird.
Ach was - das ist doch lachhaft. Ich habe derzeit eine Aufgabe, da habe ich mit C++ Code zu tun, wo eine Methode schon deutlich länger sein kann ... Datei nur 500 Zeilen ... Das ist doch keine Herausforderung :)

Aber die größte Herausforderung ist, da dann nicht den Rechner aus dem Fenster oder gegen die Wand zu werfen :)

Das aber nur als kleine Anekdote weil mir das tatsächlich derzeit ganz schön zu schaffen macht.. Aber ich hoffe, dass ich da bald durch bin mit der Aufgabe bezüglich dieses alten Bestandcodes ... :)

Aber ich gebe Dir 100% Recht.
 

mrBrown

Super-Moderator
Mitarbeiter
Ja - klar klingt das blöd, aber letztlich ist das genau die Lösung. Jeder, wirklich jeder hier, stößt irgendwann an seine Grenzen. Ich persönlich habe ein Limit bei 1.000 Codezeilen. Ich habe zwar bei 500 Codezeilen schon Bauchweh, aber 1.000 Codezeilen pro Datei sind so meine persönliche Schmerzgrenze. Wird die überschritten sehe ich bei der nächsten Refaktur zu, daß es weniger wird.
1.000 Zeilen :oops:
Ich würde jedem Anfänger sogar empfehlen, ein Zehntel davon als (weiche) Grenze zu nutzen, und sich dann auch zu zwingen, darüber nachzudenken wie man es anders und besser lösen könnte.

Da gehen durchaus mal zehn Minuten dafür drauf, sich einen vernünftigen Namen für eine Variable auszudenken: drei Minuten beim ersten Deklarieren, die restlichen sieben Minuten während verschiedener Refakturen während man die Methode schreibt. Klassen- und Methodennamen dito.
Die beiden schwierigen Dinge beim Programmieren: Bennenung von Dingen, Cache-Invalidation und off-by-one-Fehler ;)
 
Zuletzt bearbeitet:

White_Fox

Top Contributor
Zuletzt bearbeitet von einem Moderator:

mrBrown

Super-Moderator
Mitarbeiter
Ein Hoch auf die Codemap...hundert Zeilen finde ich da eigentlich in der Tat schon (@anfänger: wegsehen) lächerlich.
Lächerlich viel? :p

Ich meine 100 Zeilen als weiche Grenze durchaus vollkommen Ernst. Wobei 100 Zeilen nur der Code sind, also Leerzeilen und Kommentare nicht mitgezählt. Weiche Grenze meint dabei einfach nur, dass auch mal 107 Zeilen in Ordnung und besser sind, als irgendwo zwei Statement in eine Zeile zu quetschen und damit unter 100 zu kommen.

In eigentlich allen "Anfängerprojekten", die ich bisher erlebt hab, hatten alle Dateien mit mehr als 100 Codezeilen sehr offensichtlich zu viel zu tun. Sehr offensichtlich ist sowas wie "irgendein spezielles Dateiformat parsen und die zentrale Domänen-Logik in einer Klasse", nicht irgendwas seht spezielles wie "diesen zwei Attribute könnte man zusammenfassen und auslagern und damit könnte man drei Zeilen dort sparen". Üblicherweise sind das Dinge, die sich mit sehr wenig Aufwand refactoren lassen, oftmals indem man einfach ein, zwei Methode in eine andere Klasse verschiebt.

Der wesentliche Punkt dabei ist auch, sich selbst zu zwingen (frühzeitig) darüber nachzudenken, anstatt es einfach zu ignorieren und die Klasse immer weiter zu wachsen lassen. Dann landet man irgendwann bei riesigen Klassen, die man kaum noch auseinander gezogen bekommt.



Das ist übrigens auch in größeren Projekten durchaus machbar:
In unserem aktuellem Projekt haben mehr als 100 Codezeilen knapp 5% der Dateien. Über 200 Zeilen haben, leider, 2 Dateien (eine davon ist allerdings automatisch generiert).
 

LimDul

Top Contributor
Ich war mal neugierig. Wir haben knapp über 2000 Dateien im Projekt (sehr viel generierter Code)
40 davon über 1000 Zeilen in der Datei - davon eine Testklasse als 3t-größte Datei mit knapp 3000 Zeilen (die zugehörige Klasse selber steht bei 1200 und wird demnächst aufgesplittet - die ist zu groß)
300 Dateien über 500, aber unter 1000
1000 Dateien unter 100 Zeilen
Also ca. 600 zwischen 100 und 500 Zeilen

Schaue ich mir über SonarQube, der den Großteil des generierten Code nicht misst, die Lines to Cover an:
9 Dateien über 100 Zeilen (Spitzenreiter die Klasse die oben mit 1200 Zeilen ausgegeben ist, Sonar hat da 456 LoC).
 

White_Fox

Top Contributor
Der wesentliche Punkt dabei ist auch, sich selbst zu zwingen (frühzeitig) darüber nachzudenken, anstatt es einfach zu ignorieren und die Klasse immer weiter zu wachsen lassen. Dann landet man irgendwann bei riesigen Klassen, die man kaum noch auseinander gezogen bekommt.
Ich verstehe die Absicht durchaus, und sehe das ja genauso.
Aber 100 Codezeilen (ich rede auch nur von richtigen Codezeilen, keine Kommentare, Leerzeilen, usw.) hätte ich aus dem Bauch heraus jetzt doch als etwas wenig angesehen.

Ich habe jetzt zwar kein Skript zum messen da, aber die meisten Klassen sind bei mir auch eher kleiner. Aber es ging hier ja um die obere Grenze.

Nun denn...irgendwann kommt sicher der Tag an dem ich was verbessern will und nicht mehr weiß, was ich noch verbessern könnte. Dann sehe ich zu, wie ich alle Klassen kleiner bekomme. Also so auf grob 100 Codezeilen eindampfe...
 

LimDul

Top Contributor
Ich verstehe die Absicht durchaus, und sehe das ja genauso.
Aber 100 Codezeilen (ich rede auch nur von richtigen Codezeilen, keine Kommentare, Leerzeilen, usw.) hätte ich aus dem Bauch heraus jetzt doch als etwas wenig angesehen.

Ich habe jetzt zwar kein Skript zum messen da, aber die meisten Klassen sind bei mir auch eher kleiner. Aber es ging hier ja um die obere Grenze.

Nun denn...irgendwann kommt sicher der Tag an dem ich was verbessern will und nicht mehr weiß, was ich noch verbessern könnte. Dann sehe ich zu, wie ich alle Klassen kleiner bekomme. Also so auf grob 100 Codezeilen eindampfe...
Die Zahlen bei mir sind aus meinem aktuelle, echten Projekt (Das als Großprojekt durchgeht). Da sind von exakt 9 Klassen über 100 nicht generierte Codezeilen. Von daher durchaus machbar und sinnvoll:

1607072560167.png
 

thecain

Top Contributor
Kann ich so unterschreiben... Und die grösse in der List ist auch definitiv schon viel zu komplex und sehr schwer zu testen.

1607083803896.png
 

LimDul

Top Contributor
Man muss sich halt angewöhnen Dinge sofort zu unterteilen.
Wir haben Vaadin + eigenes Framework oben drauf als GUI. Wenn ich da eine neuen Teilbaschnitt (GUI-Bereich) anlege, ist es oft so dass da schnell 2-5 Klassen rauspurzelen:
* Für Tabellen eine Wrapper Klasse für die Zeilen
* Für eine Tabellenzeile eine Klasse
* Ggf. Klasse zum zusammenstellen der Daten / Custom Data Klasse
* Ggf. Konverter um Daten im UI richtig formatiert darzustellen
 

mrBrown

Super-Moderator
Mitarbeiter

mihe7

Top Contributor
Weder hier im Thread wird der Durchschnitt genannt noch gibt cloc den aus, oder überseh ich was? 😅

Und was meinst du mit trügerisch?
Ich meine, wenn man cloc über das ganze Projekt laufen lässt, dann bekommt man schön dargestellt, wie viele Dateien und LOCs man hat. Wenn man da den Durchschnitt bildet, dann kann aufgrund von Ausreißern ein falsches Bild gezeichnet werden.
 

mrBrown

Super-Moderator
Mitarbeiter
Ich meine, wenn man cloc über das ganze Projekt laufen lässt, dann bekommt man schön dargestellt, wie viele Dateien und LOCs man hat. Wenn man da den Durchschnitt bildet, dann kann aufgrund von Ausreißern ein falsches Bild gezeichnet werden.
Achso, das Problem hat man ja generell beim Durchschnitt. Median (und andere Quantile) sind da passender :)
 

mihe7

Top Contributor
So sieht das für einen Teil eines unserer Projekte aus:

165,5​
LOC im Mittel​
246,7​
Standardabweichung​
61,20 %​
weniger als 100 Zeilen​
76,53 %​
weniger als 200 Zeilen​
81,90 %​
weniger als 300 Zeilen​
88,19 %​
weniger als 400 Zeilen​
92,33 %​
weniger als 500 Zeilen​
 

mrBrown

Super-Moderator
Mitarbeiter
39,1​
Durchschnitt (LOC/Anzahl Dateien)
31​
Median
36​
Standardabweichung
72,6 %​
weniger als 50 Zeilen
94,6 %​
weniger als 100 Zeilen
98,8 %​
weniger als 150 Zeilen
99,6 %​
weniger als 200 Zeilen
99,8 %​
weniger als 300 Zeilen
100 %​
weniger als 400 Zeilen
 
Zuletzt bearbeitet:

mrBrown

Super-Moderator
Mitarbeiter
@LimDul könnte auf einen noch geringeren Durchschnitt kommen, zumnindest wenn man die LOC aus der Grafik und die Anzahl Klassen in der späteren Antwort nimmt.

Wobei SonarQube afaik anders misst als cloc, letzteres zählt zb auch package- und import-Statements mit.
 

mrBrown

Super-Moderator
Mitarbeiter
Hab für ein Projekt welche mit jQAssistant berechnete, allerdings weiß ich nicht wie die berechnet wurden und ob man dem trauen kann :D

Das höchste für eine Methode ist demnach 16 (ist ein sehr langes (w || x) && (y || z) ..., dürfte passen), die höchste Summe für eine Klasse ist 53.
 

LimDul

Top Contributor
@LimDul könnte auf einen noch geringeren Durchschnitt kommen, zumnindest wenn man die LOC aus der Grafik und die Anzahl Klassen in der späteren Antwort nimmt.

Wobei SonarQube afaik anders misst als cloc, letzteres zählt zb auch package- und import-Statements mit.
Ne, auf einen höheren :)
Muss ich Montag mal machen, wenn der Arbeitslaptop wieder an ist. Da werden deutlich andere Zahlen rauskommen, weil Sonar zählt ca. 30-40% der Zeilen nicht, weil das generierter Code ist.
 

mrBrown

Super-Moderator
Mitarbeiter
Hm... ich habe ältere SQ-Zahlen da, das könnte zwischen cloc und SQ ziemlich gut hinkommen.
Ich hab hier nur den Vergleich von cloc und Jacoco, das misst zumindest nur die wirklich ausfühbaren Zeilen und hat damit immer weniger als cloc.

EDIT: Ah, @LimDul hat die "Lines to Cover"-Übersicht, @thecain die "Lines of Code", letzteres passt zu den Zahlen von cloc.
 
Zuletzt bearbeitet:

LimDul

Top Contributor
Das sagt CLOC:

Code:
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Java                          2061          48128         102110         233703
-------------------------------------------------------------------------------
Ergibt einen Schnitt von 113 Zeilen pro Datei. Für detaillierte Auswertungen hab ich gerade Zeit
 

LimDul

Top Contributor
Die Zahlen kann auch bieten, selbes Projek
1607327734420.png

Allerdings sehr viel generierter Code dabei (Die dritte Klasse mit 185 ist allerdings komplett ohne und auch der Spitzenreiter bei der Länge gewesen)
 

Ähnliche Java Themen


Oben