Gute Praxis Klasse Zeilenanzahl

Question

Ich weiß, dass es keine richtige Antwort auf diese Frage gibt, ich frage nur nach Ihrer Meinung.

Ich weiß, dass das Erstellen von HUGE-Klassen-Dateien mit tausend Zeilen Code keine gute Übung ist, da es schwer zu pflegen ist und es bedeutet auch, dass Sie wahrscheinlich Ihre Programmlogik überprüfen sollten.

Ihrer Meinung nach, was für eine Klasse eine durchschnittliche Zeilenzahl ist sich in Java sagen (ich weiß nicht, ob die Wahl der Sprache etwas damit zu tun hat, sondern nur für den Fall ...)

Answer 1

Ja Ich würde sagen, es hat etwas mit der Sprache zu tun, schon allein deshalb, weil manche Sprachen ausführlicher sind als andere.

Im Allgemeinen verwende ich diese Faustregeln:

• < 300 Linien: Fein
• 300-500 Linien: vernünftige
• 500-1000 Linien: vielleicht in Ordnung, aber Plan
auf Refactoring
• > 1000 Zeilen: auf jeden Fall

natürlich Refactoring, es hängt wirklich mehr von der Art und Komplexität der Code als auf LOC, aber ich habe diese sinnvoll gefunden.

Answer 2

Im Allgemeinen ist die Anzahl der Zeilen nicht das Problem - eine etwas bessere Metrik ist die Anzahl der öffentlichen Methoden. Aber es gibt keine korrekte Zahl. Beispielsweise könnte eine Dienstprogramm-String-Klasse möglicherweise über Hunderte von Methoden verfügen, während eine Business-Level-Klasse nur ein paar haben könnte.

Wenn Sie an LOC, cyclomatic und anderen Komplexitätsmessungen interessiert sind, kann ich Quellmonitor von http://www.campwoodsw.com empfehlen, der frei ist, arbeitet mit Hauptsprachen wie Java & C++, und ist rundherum groß.

Answer 3

Ich konzentriere mich auf Methoden und (versuche), sie unter 20 Zeilen Code zu halten. Die Klassenlänge wird im Allgemeinen vom Grundsatz der einheitlichen Verantwortung bestimmt. Aber ich glaube, dass dies kein absolutes Maß ist, weil es vom Abstraktionsniveau abhängt, daher suche ich irgendwo zwischen 300 und 500 Zeilen nach dem Code für eine neue Verantwortung oder Abstraktion, die extrahiert werden soll.

Answer 4

Von Eric Raymond "The Art Of Unix Programming"

In nichtmathematischen Begriffen bedeuten Hatton empirische Ergebnisse einen Sweet-Spot zwischen 200 und 400 logischen Codezeilen, die wahrscheinlich Defektdichte, alle anderen Faktoren (wie minimiert als Programmierer Fähigkeit) gleich sein. Diese Größe ist unabhängig von der verwendeten Sprache - eine Beobachtung, die die an anderer Stelle in diesem Buch gegebene Empfehlung, mit den mächtigsten Sprachen und Werkzeugen zu programmieren, stark verstärkt. Aber hüte dich davor, diese Zahlen zu wörtlich zu nehmen. Die Methoden zum Zählen von Codezeilen variieren erheblich, je nachdem, was der Analyst als logische Zeile betrachtet und welche anderen Vorurteile (z. B. ob Kommentare entfernt werden). Hatton selbst schlägt als Faustregel eine 2x-Umwandlung zwischen logischen und physikalischen Linien vor, was auf einen optimalen Bereich von 400-800 physikalischen Linien hindeutet.

von here Genommen

Answer 5

Du hast Recht ... es gibt keine Antwort auf diese Frage. Sie können eine "Best Practice" nicht als Anzahl von Codezeilen festlegen.

Allerdings, als Richtlinie gehe ich oft durch, was ich auf einer Seite sehen kann. Sobald eine Methode nicht auf eine Seite passt, denke ich, dass ich etwas falsch mache. Was die gesamte Klasse betrifft, wenn ich nicht alle Method/Property-Header auf einer Seite sehen kann, dann muss ich vielleicht auch damit beginnen, diese zu trennen.

Noch einmal, es gibt wirklich keine Antwort, manche Dinge müssen einfach groß und komplex werden. Die Tatsache, dass du weißt, dass das schlecht ist und du denkst jetzt darüber nach, bedeutet wahrscheinlich, dass du weißt, wann du aufhören musst, wenn die Dinge außer Kontrolle geraten.

Answer 6

Klein genug, um nur die Aufgabe zu erledigen, mit der es geladen ist.

Groß genug, um nur die Aufgabe zu erledigen, mit der es geladen ist.

Nicht mehr und nicht weniger.

Answer 7

Besser, etwas wie cyclomatic complexity zu messen und das als Messgerät zu verwenden. Sie könnten es sogar in Ihr Build-Skript/ant-Datei/etc stecken.

Es ist zu einfach, selbst bei einem standardisierten Codeformat, dass Codezeilen von der tatsächlichen Komplexität der Klasse getrennt werden.

Bearbeiten: Siehe this question für eine Liste der zyklomatischen Komplexität Tools.

Answer 8

Bei Codezeilen geht es viel mehr um Ausführlichkeit als um alles andere. In dem Projekt, in dem ich gerade arbeite, haben wir einige Dateien mit über 1000 LOC. Aber, wenn Sie die Kommentare entfernen, bleibt es wahrscheinlich ungefähr 300 oder sogar weniger. Wenn Sie die Deklarationen wie

 
int someInt; 
int someOtherInt; 

auf eine Zeile ändern, wird die Datei noch kürzer.

Wenn Sie jedoch nicht ausführlich sind und immer noch eine große Datei haben, müssen Sie wahrscheinlich über Refactoring nachdenken.

Answer 9

Die kurze Antwort: weniger als 250 Zeilen.

Die kürzere Antwort: Mu.

Die längere Antwort: Ist der Code lesbar und prägnant? Hat die Klasse eine einzige Verantwortung? Wiederholt sich der Code?

Answer 10

Nach meiner Erfahrung jede Quelldatei über 1000 Textzeilen werde ich beginnen wollen, aufzubrechen. Idealerweise sollten Methoden möglichst auf einen einzigen Bildschirm passen.

In letzter Zeit habe ich festgestellt, dass das Entfernen von nicht hilfreichen Kommentaren sehr hilfreich dabei sein kann. Ich kommentieren weit sparsamer als ich vor 20 Jahren, als ich anfing zu programmieren.

Answer 11

Für mich ist das Problem nicht LOC. Was ich sehe, sind mehrere Faktoren. Zuerst überprüfe ich meine If-Else-If-Anweisungen. Wenn viele von ihnen die gleichen Bedingungen haben oder einen ähnlichen Code ausführen, versuche ich das zu reformieren. Dann schaue ich mir meine Methoden und Variablen an. In jeder einzelnen Klasse sollte diese Klasse eine primäre Funktion und nur diese Funktion haben. Wenn es Variablen und Methoden für einen anderen Bereich enthält, sollten Sie diese in ihre eigene Klasse aufnehmen. So oder so vermeiden Sie, LOC aus zwei Gründen zu zählen:

1) Es ist eine schlechte Metrik. Wenn Sie LOC zählen, zählen Sie nicht nur lange Zeilen, sondern auch Zeilen, die Leerzeichen sind und für Kommentare verwendet werden, als wären sie gleich.Sie können dies vermeiden, aber gleichzeitig zählen Sie immer noch kleine Linien und lange Linien.

2) Es ist irreführend. Lesbarkeit ist nicht nur eine Funktion von LOC. Eine Klasse kann perfekt lesbar sein, aber wenn Sie eine LOC-Zählung haben, gegen die sie verstößt, werden Sie feststellen, dass Sie hart daran arbeiten, so viele Zeilen wie möglich herauszuquetschen. Sie können sogar den Code WENIGER lesbar machen. Wenn Sie das LOC verwenden, um Variablen zuzuweisen und sie dann in einem Methodenaufruf zu verwenden, ist es besser lesbar, als die Zuweisungen dieser Variablen direkt im Methodenaufruf selbst aufzurufen. Es ist besser, 5 Zeilen lesbaren Code zu haben, als ihn in einer Zeile unlesbaren Codes zu verdichten.

Stattdessen würde ich die Tiefe des Codes und die Zeilenlänge betrachten. Das sind bessere Metriken, weil sie dir zwei Dinge sagen. Erstens, die verschachtelte Tiefe sagt Ihnen, ob Sie Logik müssen refaktoriert werden. Wenn Sie If-Anweisungen oder Schleifen betrachten, die mehr als 2 tief verschachtelt sind, sollten Sie ernsthaft über das Refactoring nachdenken. Erwägen Sie das Refactoring, wenn Sie mehr als eine Verschachtelungsebene haben. Zweitens, wenn eine Zeile lang ist, ist sie im Allgemeinen sehr unlesbar. Versuchen Sie, diese Zeile auf mehrere lesbare Zeilen zu trennen. Dies könnte Ihr LOC-Limit brechen, wenn Sie eines haben, aber es verbessert tatsächlich die Lesbarkeit.

Answer 12

Zeilenzählung == Bohnenzählung.

In dem Moment, in dem Sie Tools einsetzen, um herauszufinden, wie viele Zeilen Code eine bestimmte Datei oder Funktion hat, sind Sie verrückt, IMHO, weil Sie sich nicht mehr um die Verwaltung des Codes sorgen und bürokratisch Regeln machen und Schuld zuweisen .

Werfen Sie einen Blick auf die Datei/Funktion, und überlegen Sie, ob es noch bequem ist, mit zu arbeiten, oder beginnt unhandlich zu werden. Rufen Sie im Zweifelsfall einen Mitentwickler an (oder, wenn Sie eine One-Man-Show haben, einen Entwickler, der nicht mit dem Projekt zu tun hat), um sich einen Überblick zu verschaffen und kurz darüber zu reden.

Es ist wirklich nur das: ein Blick. Bekommt jemand anderes sofort den Code, oder ist er ein Buch für Uneingeweihte? Dieser kurze Überblick zeigt Ihnen mehr über die Lesbarkeit eines Stücks Code als alle bisher entwickelten Liniemetriken. Es hängt von so vielen Dingen ab. Sprache, Problemdomäne, Code-Struktur, Arbeitsumgebung, Erfahrung. Was für eine Funktion in einem Projekt in Ordnung ist, könnte für einen anderen völlig unverhältnismäßig sein.

Wenn Sie in einer Team-/Projektsituation sind und nicht ohne weiteres mit diesem "One Quick Look" -Ansatz übereinstimmen können, haben Sie ein soziales Problem, kein technisches Problem. (Unterschiedliche Qualitätsstandards und möglicherweise ein Kommunikationsfehler.) Regeln für Datei-/Funktionslängen zu haben wird Ihr Problem nicht lösen. Sich hinzusetzen und bei einem kühlen Getränk (oder einem Kaffee, je nachdem ...) darüber zu reden, ist eine bessere Wahl.