Ab welchem ​​Punkt / Bereich ist eine Codedatei zu groß?

Ich finde viele 2-3k-Zeilendateien und es fühlt sich nicht wirklich so an, als ob sie so groß sein sollten.

Was ist ein gutes Kriterium, um eine Quellcodedatei objektiv als "zu groß" zu bezeichnen? Gibt es eine maximale Anzahl von Zeilen, die eine Quellcodedatei haben sollte?

Als ideales Modell verwende ich die folgenden Kriterien (mit einer ähnlichen Begründung, wie Martin Beckett vorgeschlagen hat, dh in logischer Struktur und nicht in Codezeilen zu denken):

Regel 1

Eine Klasse pro Datei (in C ++: eine Klasse -> ein Header und eine Implementierungsdatei).

Regel 2

Sieben wird als die Anzahl der Objekte angesehen, die unser Gehirn gleichzeitig beobachten kann, ohne verwirrt zu werden. Oberhalb von 7 fällt es uns schwer, einen Überblick über das zu behalten, was wir sehen. Deshalb: Jede Klasse sollte nicht mehr als 7-10 Methoden haben. Eine Klasse mit mehr als 10 Methoden ist wahrscheinlich zu komplex und Sie sollten versuchen, sie zu teilen. Das Teilen ist eine sehr effektive Methode, da Sie bei jedem Teilen einer Klasse die Komplexität jeder einzelnen Klasse mindestens um den Faktor 2 verringern.

Regel 3

Ein Methodenkörper, der nicht in ein oder zwei Bildschirme passt, ist zu groß (ich gehe davon aus, dass ein Bildschirm- / Editorfenster etwa 50 Zeilen umfasst). Im Idealfall können Sie die gesamte Methode in einem Fenster anzeigen. Ist dies nicht der Fall, müssen Sie nur ein wenig nach oben und unten scrollen, ohne den Teil der Methode zu vergessen, der ausgeblendet wird. Wenn Sie also mehr als einen Bildschirm nach oben oder unten scrollen müssen, um den gesamten Methodenkörper zu lesen, ist Ihre Methode wahrscheinlich zu groß und Sie können leicht den Überblick verlieren.

Erneut kann das Teilen von Methoden mit privaten Hilfemethoden die Methodenkomplexität sehr schnell reduzieren (bei jeder Aufteilung wird die Komplexität mindestens halbiert). Wenn Sie zu viele private Hilfemethoden einführen, können Sie eine separate Klasse erstellen, um sie zu sammeln (wenn Sie mehr private Methoden als öffentliche Methoden haben, versteckt sich möglicherweise eine zweite Klasse in Ihrer Hauptklasse).

Stellen Sie diese sehr groben Schätzungen zusammen:

• Höchstens eine Klasse pro Quelldatei.
• Höchstens 10 öffentliche Methoden pro Klasse.
• Höchstens 10 Privatmethoden pro Klasse.
• Höchstens 100 Zeilen pro Methode.

Eine Quelldatei mit mehr als 2000 Zeilen ist wahrscheinlich zu groß und zu unübersichtlich.

Dies ist wirklich eine sehr grobe Schätzung, und ich befolge diese Kriterien nicht systematisch (insbesondere, weil nicht immer genug Zeit für eine ordnungsgemäße Umgestaltung zur Verfügung steht). Wie Martin Beckett angedeutet hat, gibt es Situationen, in denen eine Klasse eine große Sammlung von Methoden ist und es keinen Sinn macht, sie künstlich aufzuteilen, um die Klasse zu verkleinern.

Wie auch immer, meiner Erfahrung nach wird eine Datei unlesbar, wenn einer der oben genannten Parameter nicht beachtet wird (z. B. ein Text mit einer 300-Zeilen-Methode, der sich über sechs Bildschirme erstreckt, oder eine Quelldatei mit 5.000 Codezeilen).

Nein - nicht in Codezeilen. Der Treiber sollte logisch gruppiert sein. Es sollten zum Beispiel nicht mehrere Klassen in einer großen Datei sein

Wenn Sie eine Klasse hätten, die aus legitimen Gründen ein paar hundert Methoden hat (was bei der 3D-Modellierung nicht unmöglich ist), wäre es weitaus weniger praktisch, diese in beliebige Dateien aufzuteilen. Früher mussten wir dies tun, wenn der Speicher knapper und die Prozessoren langsamer waren - und es war mühsam, ständig nach der Funktionsdefinition zu suchen.

Wenn der Code darin nicht mehr zu warten ist. Dh: Sie können nicht einfach durch Betrachten des Codes erkennen, ob die gesuchte Methode / Klasse / Funktion vorhanden ist (und bearbeitet / debuggt werden muss), oder nicht, und wenn ja, wo sie sich befindet.

Ihre IDE / Editor-Auswahl und -Funktionen beeinflussen jedoch die tatsächliche Quantifizierung dieser Obergrenze. Code Folding , Function / Method Listing und Lookup werden den Moment verschieben, in dem sich dieses Entwicklungsszenario darstellt.

Aber wenn es so ist, ist es Zeit, es zu teilen.

Hier ist eine alternative Ansicht: Sie fragen sich, wie Sie die Dateigröße begrenzen können. Meiner Meinung nach gibt es viele Faktoren, die große Codedateien sehr problematisch machen. Manchmal ist die Codedatei riesig, aber ihr Inhalt ist gut gruppierter und äußerst sauberer Code, sodass die Größe keine wesentlichen Probleme verursacht. Ich habe viele Dateien gesehen, die trotz des hohen LOC sehr gut lesbar sind.

Anstatt auf die LOC-Metrik zuzugreifen, würde ich lieber die Verlaufsdaten verwenden, um zu verstehen, wie oft der Code in diesen großen Dateien beschädigt wird. Normalerweise ist der Grund dafür, dass die Entwickler keine Zeit haben, die relevanten anderen Stellen in derselben Datei zu überprüfen und die Änderung mit einer "Schnellkorrektur" -Mentalität ohne ausreichendes Verständnis vorzunehmen.

Die größere Gefahr ist das Vorhandensein von Code zum Kopieren und Einfügen. Copy-Paste-Codierung beschleunigt natürlich auch das LOC-Wachstum. Ich denke, das Ausschalten von Copy-Paste ist noch wichtiger, als LOC unter einer magischen Zahl zu halten. Neben dem reinen Kopieren und Einfügen besteht bei großen Dateien eine zweite Gefahr: Überlappende Funktionen. Je größer die Datei ist, desto wahrscheinlicher ist es, dass Sie ein Snippet erneut implementieren, das sich bereits in einem anderen Abschnitt derselben Datei befindet.

Solange die Fehlerbehebungsrate (Verhältnis der Fehlerbehebungs-Commits zu allen Commits) für die größeren Dateien niedrig ist, ist die Situation tolerierbar. Bitte probieren Sie git loges aus und sehen Sie sich an, wie viele der Commits mit Fehlern zusammenhängen. Oder verwenden Sie ein Tool, das es automatisch analysieren und visualisieren kann, z . B. Softagram .

Betrachten Sie das Metaphor. Wenn es um die Codelänge geht, sollten wir meines Erachtens Folgendes berücksichtigen:

The Cat in The Hat (50 pp.)

und

Lord of The Rings (1,178 pp.)

Es ist nichts falsch mit Lord of the Rings. Es ist ein fabelhaftes Buch. The Cat in the Hatist auch ein tolles Buch. Beide können von einem 5-Jährigen verstanden werden, aber nur einer ist inhaltlich besser geeignet.

Meines Erachtens sollte das Schreiben von Code für einen Fünfjährigen Sinn machen, wann immer wir können. Cyclomatic Complexityist ein wichtiges Konzept, das Entwickler beim Generieren von Code berücksichtigen sollten. Verwenden und Erstellen von Bibliotheken, um die Funktionalität und Wiederverwendbarkeit von Code so weit wie möglich zu verbessern. Auf diese Weise kann unser Code mehr Bände sprechen, als wir geschrieben sehen.

Die meisten von uns schreiben keinen Assembler-Code . Die Wurzel unseres Codes ist jedoch die Assemblierung. Das Durchsuchen von 10000 Zeilen Assembler ist schwieriger als 10000 Zeilen Python, wenn es richtig ausgeführt wird.

Für einige Arbeiten müssen jedoch 500 bis 1000 Zeilen geschrieben werden. Unser Ziel mit Code sollte es sein, 300 Zeilen sauberen Code zu schreiben.

Als Entwickler wollen wir "Lord of The Rings" schreiben. Bis wir einen Bug bekommen und uns wünschen, wir würden "Cat in the Hat" schreiben. Machen Sie die Kodierung nicht zu einem Maß für das Ego. Lass die Dinge einfach funktionieren.

Entwickler wollen keinen Code dokumentieren (ich liebe dokumentierten Code persönlich, ich bin nicht so egoistisch). Schreiben Sie also keinen Code, den nur Sie verstehen / lesen können. Cat in the HatCode schreiben .

Wir alle wissen, dass Sie JRR Tolken sind (in Ihrem Kopf). Denken Sie daran, dass Sie mit fehlerfreiem Code nichts zu beweisen haben.

Ein weiterer Grund für die Metapher.

Überfordern Sie nicht den Leser, der den Reichtum verbreitet. Wenn Sie mit einer Gruppe von Menschen arbeiten und diese alle eine große Datei ändern müssen, werden Sie sich wahrscheinlich in gitdie Hölle der Verschmelzung begeben.

Jeder liebt es, neu zu gründen.

-> Sagte niemand jemals!

TL; DR Lesbarkeit im Fokus. Verteilen Sie Ihren Code und Helfer so weit wie möglich auf mehrere Zeilen und Dateien. Werfen Sie nicht 8 oder 9 Klassen in eine einzelne Datei. Dadurch ist der Code schwer zu lesen und schwerer zu warten. Wenn Sie einen großen Bedingungscode oder eine große Schleife haben, können Sie diese in Lambdas ändern, sofern die Sprache dies unterstützt. Dienstprogramme sollten als eine großartige Möglichkeit angesehen werden, um die Lesbarkeit von Code zu verbessern. Vermeiden Sie schweres Nisten.