Was ist für Sie die ideale Länge einer Methode? [geschlossen]


122

In der objektorientierten Programmierung gibt es natürlich keine genaue Regel für die maximale Länge einer Methode, aber ich fand diese beiden Anführungszeichen immer noch etwas widersprüchlich. Ich würde gerne hören, was Sie denken.

In Clean Code: Ein Handbuch für agiles Software-Handwerk , sagt Robert Martin:

Die erste Regel für Funktionen ist, dass sie klein sein sollten. Die zweite Regel von Funktionen ist, dass sie kleiner sein sollten. Funktionen sollten nicht 100 Zeilen lang sein. Funktionen sollten selten 20 Zeilen lang sein.

und er gibt ein Beispiel aus Java-Code, den er von Kent Beck sieht:

Jede Funktion in seinem Programm war nur zwei, drei oder vier Zeilen lang. Jeder war transparent offensichtlich. Jeder erzählte eine Geschichte. Und jeder führte Sie in einer zwingenden Reihenfolge zum nächsten. So kurz sollten Ihre Funktionen sein!

Das hört sich gut an, aber in Code Complete sagt Steve McConnell etwas ganz anderes:

Die Routine sollte organisch auf 100 bis 200 Zeilen anwachsen können. Nach jahrzehntelangen Beweisen sind Routinen dieser Länge nicht fehleranfälliger als kürzere Routinen.

Und er gibt einen Hinweis auf eine Studie, die besagt, dass die Entwicklung von Routinen mit 65 Zeilen oder mehr billiger ist.

Gibt es also eine funktionale Best Practice für Sie, obwohl es unterschiedliche Meinungen zu diesem Thema gibt?


17
Funktionen sollten leicht verständlich sein. Daraus sollte sich je nach Sachlage die Länge ergeben.
Henk Holterman

56
Ich denke, die reale Grenze liegt bei 53 Zeilen. Mit einer durchschnittlichen Zeilengröße von 32,4 Zeichen. Im Ernst, es gibt keine endgültige Antwort. Eine 100-Zeilen-Methode kann sehr klar und wartbar sein, und eine 4-Zeilen-Methode kann ein Albtraum sein. Im Allgemeinen haben lange Methoden jedoch tendenziell zu viele Verantwortlichkeiten und sind schwerer zu verstehen und zu pflegen als kleinere. Ich würde in Verantwortlichkeiten denken und versuchen, eine einzige Verantwortung pro Methode zu haben.

23
In der Programmierung gibt es einen Begriff namens „funktionale Kohärenz“. Die Länge einer Funktion sollte variieren können, vorausgesetzt, ihre Implementierung bildet immer noch eine einzige zusammenhängende Logikeinheit in Ihrer Anwendung. Das willkürliche Aufteilen von Funktionen, um sie zu verkleinern, erhöht die Wahrscheinlichkeit, dass der Code aufgebläht wird und die Wartbarkeit beeinträchtigt wird.

9
Wenn Sie die Komplexität Ihrer Funktionen begrenzen möchten, sollten Sie deren zyklomatische Komplexität und nicht deren Länge messen . Eine switchAnweisung mit 100 caseBedingungen kann besser verwaltet werden als 10 Ebenen von ifAnweisungen, die ineinander verschachtelt sind.

10
Bob Martins Ansatz stammt aus dem Jahr 2008, der von Steve Mc Connell aus dem Jahr 1993. Sie haben unterschiedliche Philosophien darüber, was "guter Code" ist, und IMHO Bob Martin versucht, ein viel höheres Maß an Codequalität zu erreichen.
Doc Brown

Antworten:


115

Funktionen sollten normalerweise kurz sein, zwischen 5 und 15 Zeilen ist meine persönliche "Faustregel" beim Codieren in Java oder C #. Dies ist aus mehreren Gründen eine gute Größe:

  • Es passt problemlos auf Ihren Bildschirm, ohne zu scrollen
  • Es geht um die konzeptionelle Größe, die Sie in Ihrem Kopf halten können
  • Es ist sinnvoll genug, um eine eigene Funktion zu benötigen (als eigenständiges, sinnvolles Stück Logik).
  • Eine Funktion mit weniger als 5 Zeilen ist ein Hinweis darauf, dass Sie den Code möglicherweise zu stark aufteilen (was das Lesen / Verstehen erschwert, wenn Sie zwischen Funktionen navigieren müssen). Entweder das oder Sie vergessen Ihre Sonderfälle / Fehlerbehandlung!

Ich halte es jedoch nicht für hilfreich, eine absolute Regel festzulegen, da es immer gültige Ausnahmen / Gründe gibt, von der Regel abzuweichen:

  • Eine einzeilige Accessor-Funktion, die eine Typumwandlung ausführt, ist in einigen Situationen eindeutig akzeptabel.
  • Es gibt einige sehr kurze, aber nützliche Funktionen (zB Swap, wie vom Benutzer nicht erwähnt), die eindeutig weniger als 5 Zeilen benötigen. Keine große Sache, ein paar 3-Zeilen-Funktionen schaden Ihrer Codebasis nicht.
  • Eine 100-Zeilen-Funktion, bei der es sich um eine einzelne große switch-Anweisung handelt, kann akzeptabel sein, wenn äußerst klar ist, was gerade getan wird. Dieser Code kann konzeptionell sehr einfach sein, selbst wenn viele Zeilen zur Beschreibung der verschiedenen Fälle erforderlich sind. Manchmal wird vorgeschlagen, dies in separate Klassen umzugestalten und mithilfe von Vererbung / Polymorphismus zu implementieren, aber meiner Meinung nach geht dies zu weit - ich hätte lieber nur eine große 40-Wege-switch-Anweisung als 40 neue Klassen, die behandelt werden müssen zu einer 40-Wege-switch-Anweisung, um sie zu erstellen.
  • Eine komplexe Funktion kann viele Zustandsvariablen enthalten, die sehr unübersichtlich werden, wenn sie als Parameter zwischen verschiedenen Funktionen übergeben werden. In diesem Fall könnten Sie vernünftigerweise ein Argument dafür vorbringen, dass der Code einfacher und leichter zu befolgen ist, wenn Sie alles in einer einzigen großen Funktion belassen (obwohl Mark zu Recht darauf hinweist, dass dies auch ein Kandidat für die Umwandlung in eine Klasse sein könnte, um beide logischen Elemente zusammenzufassen und Staat).
  • Manchmal haben kleinere oder größere Funktionen Leistungsvorteile (möglicherweise aufgrund von Inlining- oder JIT-Gründen, wie Frank erwähnt). Dies ist in hohem Maße von der Implementierung abhängig, kann jedoch einen Unterschied bewirken - stellen Sie sicher, dass Sie einen Benchmark erstellen!

Verwenden Sie also im Grunde den gesunden Menschenverstand , halten Sie sich in den meisten Fällen an kleine Funktionsgrößen, aber seien Sie nicht dogmatisch, wenn Sie einen wirklich guten Grund haben, eine ungewöhnlich große Funktion zu erstellen.


9
Es gibt auch einen technischen / perfekten Grund für kurze Methoden: JIT-Cache-Treffer. Es ist wahrscheinlicher, dass viele kleinere, wiederverwendbare Methoden zuvor aufgerufen wurden. Ach ja, StackTraces konzentrieren sich mehr auf die Logik des Pops.
Luke Puplett

20
"Nutze den gesunden Menschenverstand" ist der wichtigste Rat
Simon

Man sollte sich darüber im Klaren sein, dass diese Heuristik aufgrund der Tiefe des Stapels in Haltepunkten beim Debuggen zu Beschwerden über "Ravioli-Code" führt.
Frank Hileman

5
@FrankHileman Ich werde jeden Tag Ravioli über Spaghetti trinken, wenn ich Code schreibe

1
@Schneemann: Diese Optionen schließen sich nicht gegenseitig aus. Kurze Stapeltiefen ohne Spaghetti sind ideal. Tiefe Stapeltiefen mit Spaghetti an der Seite?
Frank Hileman

30

Obwohl ich mit den Kommentaren anderer übereinstimme, als sie sagten, dass es keine strengen Regeln für die richtige LOC-Nummer gibt, wette ich, wenn wir auf die Projekte zurückblicken, die wir in der Vergangenheit betrachtet haben, und jede Funktion oben identifizieren, sagen wir 150 Codezeilen. Vermutlich stimmen wir überein, dass 9 von 10 dieser Funktionen die SRP (und sehr wahrscheinlich auch die OCP) brechen, zu viele lokale Variablen und zu viel Kontrollfluss aufweisen und im Allgemeinen schwer zu lesen und zu warten sind.

Während LOC kein direkter Indikator für schlechten Code ist, ist es sicherlich ein anständiger indirekter Indikator dafür, dass bestimmte Funktionen besser geschrieben werden könnten.

In meinem Team fiel ich in die Position eines Leaders und aus irgendeinem Grund scheinen mir die Leute zuzuhören. Ich habe mich im Allgemeinen darauf geeinigt, dem Team mitzuteilen, dass, obwohl es kein absolutes Limit gibt, jede Funktion mit mehr als 50 Codezeilen bei der Codeüberprüfung mindestens eine rote Fahne setzen sollte, damit wir sie uns noch einmal ansehen und neu bewerten für Komplexität und SRP / OCP-Verstöße. Nach diesem zweiten Blick lassen wir es vielleicht in Ruhe oder ändern es, aber es bringt die Leute dazu, über diese Dinge nachzudenken.


3
Dies erscheint sinnvoll - LOC bedeutet in Bezug auf Komplexität oder Codequalität nichts, kann jedoch ein guter Indikator für die Möglichkeit sein, dass Dinge überarbeitet werden sollten.
Cori

4
"stimmen überein, dass 9 von 10 dieser Funktionen SRP brechen" - Ich bin anderer Meinung, ich bin ziemlich sicher, dass 10 von 10 dieser Funktionen es brechen werden ;-)
Doc Brown

1
+1 für das Auslösen eines Flags während der Codeüberprüfung: Mit anderen Worten, keine harte und schnelle Regel, aber lasst uns diesen Code als Gruppe diskutieren.

22

Ich bin in ein Projekt eingetreten, das sich nicht um Codierungsrichtlinien gekümmert hat. Wenn ich in den Code schaue, finde ich manchmal Klassen mit mehr als 6000 Codezeilen und weniger als 10 Methoden. Dies ist ein Horrorszenario, wenn Sie Fehler beheben müssen.

Eine allgemeine Regel, wie groß eine Methode maximal sein sollte, ist manchmal nicht so gut. Ich mag die Regel von Robert C. Martin (Onkel Bob): "Methoden sollten klein sein, kleiner als klein". Ich versuche diese Regel die ganze Zeit anzuwenden. Ich versuche, meine Methoden einfach und klein zu halten, indem ich klarstelle, dass meine Methode nur eine Sache und nichts weiter tut.


4
Ich verstehe nicht, warum eine 6000-Zeilen-Funktion schwerer zu debuggen ist als eine kürzere ... Es sei denn, es gibt auch andere Probleme (z. B. Wiederholung)
Calmarius

17
Es hat nichts mit Debuggen zu tun. Es geht um Komplexität und Wartbarkeit. Wie würden Sie eine 6000-Zeilen-Methode erweitern oder ändern, die von einer anderen durchgeführt wird?
Smokefoot

10
@Calmarius Der Unterschied besteht normalerweise darin, dass 6000 Zeilenfunktionen dazu neigen, lokale Variablen zu enthalten, die sehr weit entfernt (visuell) deklariert wurden, was es dem Programmierer erschwert, den mentalen Kontext aufzubauen, der für ein hohes Vertrauen in den Code erforderlich ist. Können Sie sicher sein, wie eine Variable zu einem bestimmten Zeitpunkt initialisiert und aufgebaut wird? Sind Sie sicher, dass nichts mit Ihrer Variablen zu tun hat, nachdem Sie sie in Zeile 3879 gesetzt haben? Auf der anderen Seite können Sie mit 15 Zeilenmethoden sicher sein.
Daniel B

8
@Calmarius stimmte zu, aber beide Aussagen sprechen gegen 6000 LOC-Funktionen.
Daniel B

2
Eine lokale Variable in einer 600-Zeilen-Methode ist im Wesentlichen eine globale Variable.
MK01

10

Es geht nicht um die Anzahl der Zeilen, es geht um SRP. Nach diesem Prinzip sollte Ihre Methode nur eines tun.

Wenn Ihre Methode dies UND dies UND dieses ODER das macht => dann macht sie wahrscheinlich zu viel. Versuchen Sie, diese Methode zu betrachten und zu analysieren: "Hier erhalte ich diese Daten, sortiere sie und erhalte benötigte Elemente" und "Hier verarbeite ich diese Elemente" und "Hier kombiniere ich sie schließlich, um das Ergebnis zu erhalten". Diese "Blöcke" sollten auf andere Methoden umgestaltet werden.

Wenn Sie einfach SRP folgen, wird der größte Teil Ihrer Methode klein und mit klarer Absicht sein.

Es ist nicht richtig zu sagen "diese Methode ist> 20 Zeilen, so ist es falsch". Es kann ein Hinweis darauf sein, dass mit dieser Methode etwas nicht mehr stimmt.

Möglicherweise haben Sie einen Switch mit 400 Leitungen in einer Methode (kommt häufig in der Telekommunikation vor), und es liegt immer noch in der alleinigen Verantwortung, und es ist vollkommen in Ordnung.


2
Große switch-Anweisungen, Ausgabeformate, Definitionen von Hashes / Wörterbüchern, die in manchen Datenbanken eher hartcodiert als flexibel sein sollten, kommen häufig vor und sind vollkommen in Ordnung. Solange die Logik geteilt ist, seid ihr alle gut. Eine große Methode könnte Sie auffordern, darüber nachzudenken, ob ich das aufteilen soll. Die Antwort könnte sehr gut "Nein, das ist in Ordnung, wie es ist" sein (oder ja, das ist ein absolutes Chaos)
Martijn

Was bedeutet "SRP"?
thomthom

3
SRP steht für Einzel Prinzip Verantwortung und besagt , dass jede Klasse (oder Methode) nur eine Verantwortung haben sollte. Es hängt mit Zusammenhalt und Kopplung zusammen. Wenn Sie der SRP folgen, haben Ihre Klassen (oder Methoden) eine gute Kohäsion, aber die Kopplung kann erhöht werden, weil Sie am Ende mehr Klassen (oder Methoden) haben.
Kristian Duske

+1 für SRP. Indem Sie zusammenhängende Funktionen schreiben, können Sie diese einfacher im funktionalen Stil kombinieren, um komplexere Ergebnisse zu erzielen. Am Ende ist es besser, dass eine Funktion aus drei anderen Funktionen besteht, die zusammengeklebt wurden, als dass eine einzelne Funktion drei diskrete, wenn auch irgendwie verwandte Dinge ausführt.
Mario T. Lanza

Ja, aber was ist eine einzige Verantwortung. Es ist nur ein Konzept, das in deinem Kopf kreiert wurde. Wenn Sie 400 Zeilen für eine einzelne Verantwortung benötigen, ist Ihr Konzept der einzelnen Verantwortung wahrscheinlich ganz anders als meins
Xitcod13

9

Es hängt im Ernst davon ab, dass es auf diese Frage keine eindeutige Antwort gibt, da die Sprache, mit der Sie arbeiten, die fünf bis fünfzehnten Zeilen, die in dieser Antwort erwähnt werden, möglicherweise für C # oder Java funktionieren, in anderen Sprachen jedoch nicht Sie viel zu arbeiten. Abhängig von der Domäne, in der Sie arbeiten, werden Sie möglicherweise Codeeinstellungswerte in eine große Datenstruktur schreiben. Sollten Sie bei einigen Datenstrukturen möglicherweise Dutzende von Elementen festlegen müssen, um Funktionen zu trennen, nur weil Ihre Funktion lange ausgeführt wird?

Wie andere angemerkt haben, ist die beste Faustregel, dass eine Funktion eine einzelne logische Entität sein sollte, die eine einzelne Aufgabe behandelt. Wenn Sie versuchen, drakonische Regeln durchzusetzen, die besagen, dass Funktionen nicht länger als n Zeilen sein dürfen, und Sie diesen Wert zu klein machen, wird der Code schwerer lesbar, da Entwickler versuchen, die Regel mit ausgefallenen Tricks zu umgehen. Wenn Sie den Wert zu hoch einstellen, ist dies ebenfalls kein Problem und kann trotz Faulheit zu fehlerhaftem Code führen. Am besten führen Sie einfach Codeüberprüfungen durch, um sicherzustellen, dass die Funktionen eine einzelne Aufgabe bearbeiten, und lassen Sie es dabei.


8

Ich denke, ein Problem dabei ist, dass die Länge einer Funktion nichts über ihre Komplexität aussagt. LOC (Lines of Code) sind ein schlechtes Instrument, um etwas zu messen.

Eine Methode sollte nicht übermäßig komplex sein, aber es gibt Szenarien, in denen eine lange Methode einfach verwaltet werden kann. Beachten Sie, dass das folgende Beispiel nicht besagt, dass es nicht in Methoden aufgeteilt werden kann, sondern nur, dass die Methoden die Wartbarkeit nicht ändern.

Ein Handler für eingehende Daten kann beispielsweise eine große switch-Anweisung und dann einen einfachen Code pro Fall haben. Ich habe einen solchen Code - der eingehende Daten von einem Feed verwaltet. 70 (!) Numerisch codierte Handler. Jetzt wird man sagen "benutze Konstanten" - ja, außer dass die API sie nicht bereitstellt und ich hier gerne in der Nähe von "Quelle" bleibe. Methoden? Sicher - leider verarbeiten alle Daten aus denselben zwei riesigen Strukturen. Keine Vorteile bei der Abspaltung, außer vielleicht mehr Methoden (Lesbarkeit). Der Code ist an sich nicht komplex - ein Schalter, abhängig von einem Feld. Dann hat jeder Fall einen Block, der x Datenelemente analysiert und veröffentlicht. Kein Wartungsalptraum. Es gibt eine Wiederholungsbedingung "if", die bestimmt, ob ein Feld Daten enthält (pField = pFields [x], wenn pField-> IsSet () {blabla}) - so ziemlich für jedes Feld.

Ersetzen Sie dies durch eine viel kleinere Routine, die eine verschachtelte Schleife und viele echte Schaltanweisungen enthält, und eine riesige Methode kann einfacher zu warten sein als eine kleinere.

Also, tut mir leid, LOC ist zunächst keine gute Messung. Wenn überhaupt, sollten Komplexität / Entscheidungspunkte verwendet werden.


1
LOC sind ein gutes Werkzeug für den Bereich, in dem sie eine relevante Maßnahme darstellen - sehr große Projekte, mit deren Hilfe geschätzt werden kann, wie lange ein ähnliches Projekt möglicherweise abgeschlossen sein wird. Darüber hinaus neigen die Menschen dazu, sich zu viele Sorgen um sie zu machen.
rjzii

Richtig. Es ist nicht so, dass LOC nicht davon abhängt, wie aussagekräftig ich den Code schreibe, wie die Formatierungsanforderungen usw. sind. LOC ist völlig ungeeignet und kann von MBA-Studenten ohne jegliche Erfahrung verwendet werden. Nur. Es steht Ihnen frei, sich in die Liste der Personen zu setzen, die nicht verstehen, warum LOC eine schlechte Messung ist, aber dies lässt Sie eindeutig nicht als jemanden erscheinen, dem Sie zuhören können.
TomTom

Bitte überprüfen Sie noch einmal, was ich gesagt habe. Ich habe festgestellt, dass LOC nur für einen Mess- und Verwendungsbereich ein gutes Werkzeug ist (dh extrem große Projekte, bei denen sie zur Schätzung herangezogen werden können). Alles, was kleiner ist als das Große, und sie verwenden die meisten, wenn nicht sogar alle Werte für alles, was über schnelle Hörproben hinausgeht, um die Menschen bei Laune zu halten. Sie sind so etwas wie der Versuch, anhand von Lichtjahren zu messen, wie fair das Café vom Büro aus ist. Sicher können Sie das, aber die Messung ist nutzlos. Aber wenn Sie Entfernungen zwischen Sternen besprechen müssen, funktionieren sie großartig.
rjzii

2
+1 Eine Funktion sollte den gesamten Code enthalten, den sie zur Ausführung der Funktion benötigt. Es sollte nur eine Sache und eine Sache tun - aber wenn das 1000 Codezeilen braucht, dann ist es auch so.
James Anderson

Ich habe Handler für eingehende Socket-Daten geschrieben und ja, sie können tausend oder mehr LOC erfordern. Ich kann jedoch einerseits zählen, wie oft ich das getan habe, und kann nicht zählen, wie oft es nicht der richtige Weg zum Codieren war.

7

Ich werde nur noch ein Zitat einwerfen.

Programme müssen geschrieben werden, damit die Benutzer sie lesen können, und nur im Übrigen, damit Maschinen ausgeführt werden können

- Harold Abelson

Es ist sehr unwahrscheinlich, dass Funktionen, die auf 100-200 anwachsen, dieser Regel folgen


1
Außer wenn sie einen Schalter enthalten.
Calmarius

1
oder bauen ein Objekt auf der Grundlage der Ergebnisse einer Datenbankabfrage , die Dutzende von Feldern pro Zeile in der Ergebnismenge zurück ...
jwenting

Datenbankergebnisse sind mit Sicherheit eine akzeptable Ausnahme. Außerdem handelt es sich in der Regel um "dumme" Anweisungen, die eine Instanz einer Klasse (oder was auch immer) auffüllen, anstatt dass Logik befolgt werden muss.
MetalMikester

6

Ich bin seit 1970 in diesem verrückten Schläger, auf die eine oder andere Weise.

In der ganzen Zeit habe ich mit zwei Ausnahmen, auf die ich gleich eingehen werde, NIEMALS eine gut gestaltete "Routine" (Methode, Prozedur, Funktion, Subroutine, was auch immer) gesehen, die mehr als eine gedruckte Seite sein MUSS ( etwa 60 Zeilen) lang. Die überwiegende Mehrheit von ihnen war ziemlich kurz, in der Größenordnung von 10-20 Zeilen.

Ich habe jedoch eine Menge "Stream-of-Awareness" -Code gesehen, der von Leuten geschrieben wurde, die anscheinend noch nie von Modularisierung gehört haben.

Die beiden Ausnahmen waren sehr spezielle Fälle. Eines ist eigentlich eine Klasse von Ausnahmefällen, die ich zusammenfasse: große endliche Automaten, die als große hässliche switch-Anweisungen implementiert sind, normalerweise, weil es keinen saubereren Weg gibt, sie zu implementieren. Diese Dinge werden normalerweise in automatisierten Testgeräten angezeigt und analysieren Datenprotokolle des getesteten Geräts.

Das andere war die Photonentorpedoroutine aus dem Spiel Matuszek-Reynolds-McGehearty-Cohen STARTRK, geschrieben in CDC 6600 FORTRAN IV. Es musste die Kommandozeile analysieren, dann den Flug jedes Torpedos mit Störungen simulieren, die Interaktion zwischen dem Torpedo und jeder Art von Dingen überprüfen, die es treffen konnte, und ach übrigens Rekursion simulieren, um 8-Wege-Konnektivität an Ketten von zu tun Novae vom Torpedieren eines Sterns, der neben anderen Sternen lag.


2
+1 für die "Get off my Lawn" -Stimmung, die ich aus dieser Antwort erhalte. Auch aus persönlichen Erfahrungen vor OOP waren Sprachen weit verbreitet.

Es ist nicht so sehr eine Beobachtung, dass ich viel Mistcode gesehen habe, und es scheint schlimmer zu werden.
John R. Strohm

Mein Chef hat die Angewohnheit, mehrere hundert Zeilen lang zu schreiben, oft mit mehreren Ebenen verschachtelter Ifs. Er verwendet auch Teilklassen (.NET), um eine Klasse in mehrere Dateien "aufzuteilen", damit er behaupten kann, sie kurz zu halten. Das sind nur zwei Dinge, mit denen ich mich befassen muss. Ich mache das seit ungefähr 25 Jahren und kann bestätigen, dass es immer schlimmer wird. Und jetzt ist es Zeit für mich, mich wieder auf dieses Chaos einzulassen.
MetalMikester

5

Wenn ich eine lange Methode finde, könnte ich wetten, dass diese Methode nicht richtig Unit-getestet ist oder die meiste Zeit überhaupt keinen Unit-Test hat. Wenn Sie mit TDD beginnen, werden Sie niemals 100-Zeilen-Methoden mit 25 verschiedenen Verantwortlichkeiten und 5 verschachtelten Schleifen aufbauen. Tests verpflichten Sie, Ihr Chaos ständig zu überarbeiten und Onkel Bobs sauberen Code zu schreiben.


2

Es gibt keine absoluten Regeln für die Länge der Methode, aber die folgenden Regeln waren nützlich:

  1. Der Hauptzweck der Funktion besteht darin, den Rückgabewert zu finden. Es gibt keinen anderen Grund für seine Existenz. Sobald dieser Grund erfüllt ist, sollte kein weiterer Code eingefügt werden. Dies hält Funktionen notwendigerweise klein. Der Aufruf anderer Funktionen sollte nur erfolgen, wenn dies das Auffinden des Rückgabewerts erleichtert.
  2. Andererseits sollten die Schnittstellen klein sein. Dies bedeutet, dass Sie entweder eine große Anzahl von Klassen oder große Funktionen haben - eine der beiden wird passieren, sobald Sie genug Code haben, um etwas Bedeutendes zu tun. Große Programme können beides haben.

1
Was ist mit Nebenwirkungen - Schreiben in eine Datei, Zurücksetzen des Status usw.?
Vorac

2

Meinen die Autoren das Gleiche mit "Funktion" und "Routine"? Wenn ich "function" sage, meine ich normalerweise eine Subroutine / Operation, die einen Wert und "procedure" für eine zurückgibt, die dies nicht tut (und deren Aufruf zu einer einzigen Anweisung wird). Dies ist in SE in der realen Welt keine alltägliche Unterscheidung, aber ich habe sie in Anwendertexten gesehen.

In beiden Fällen gibt es keine richtige Antwort darauf. Ich würde erwarten, dass die Bevorzugung der einen oder der anderen Sprache, des Projekts und der Organisation sehr unterschiedlich ist (wenn es überhaupt eine Präferenz gibt). Genau wie bei allen Code-Konventionen.

Das einzige, was ich hinzufügen möchte, ist, dass die Behauptung "lange Operationen sind nicht fehleranfälliger als kurze Operationen" nicht strikt wahr ist. Zusätzlich zu der Tatsache, dass mehr Code mehr potenziellem Fehlerraum entspricht, ist es offensichtlich, dass das Aufteilen von Code in Segmente Fehler sowohl leichter zu vermeiden als auch leichter zu lokalisieren macht. Andernfalls gäbe es keinen Grund, Code in Teile zu zerlegen, außer bei Wiederholungen. Dies ist jedoch möglicherweise nur dann der Fall, wenn die Segmente so gut dokumentiert sind, dass Sie die Ergebnisse eines Operationsaufrufs ermitteln können, ohne den tatsächlichen Code durchzulesen oder nachzuvollziehen (Design-by-Contract basierend auf Spezifikationen und nicht auf konkreten Abhängigkeiten zwischen Codebereichen).

Wenn Sie möchten, dass längere Vorgänge gut funktionieren, möchten Sie möglicherweise strengere Codekonventionen anwenden, um sie zu unterstützen. Das Verwerfen einer return-Anweisung mitten in einer Operation kann für eine kurze Operation in Ordnung sein, aber bei längeren Operationen kann dies einen großen Codeabschnitt erzeugen, der bedingt ist, aber offensichtlich nicht von einem schnellen Durchlesen abhängig ist (nur für ein Beispiel).

Ich würde also denken, dass der Stil, bei dem es weniger wahrscheinlich ist, dass er mit Fehlern behaftet ist, zu einem großen Teil davon abhängt, welche Konventionen Sie für den Rest Ihres Codes einhalten. :)


1

IMHO sollten Sie nicht Bildlaufleiste verwenden müssen, um Ihre Funktion zu lesen. Sobald Sie die Bildlaufleiste bewegen müssen, dauert es einige Zeit, um zu verstehen, wie die Funktion funktioniert.

Dementsprechend hängt es von der üblichen Programmierumgebung Ihrer Teamarbeit ab (Bildschirmauflösung, Editor, Schriftgröße, etc ...). In den 80er Jahren waren es 25 Zeilen und 80 Spalten. Jetzt zeige ich in meinem Editor fast 50 Zeilen an. Die Anzahl der angezeigten Spalten hat sich nicht geändert, seit ich meinen Bildschirm zweigeteilt habe, um jeweils zwei Dateien anzuzeigen.

Kurz gesagt, es hängt vom Setup Ihrer Mitarbeiter ab.


2
Waren es damals nicht eher 24 Zeilen? Ich denke an 3270 oder 9750 Terminals, bei denen der 25. die Statuszeile war. Darauf folgten die Terminal-Emulationen.
ott--

Einige Systeme / Editoren hatten von Anfang an 40 oder 50 Zeilen. Heutzutage sind 150 Zeilen keine Seltenheit und 200+ sind machbar, das ist also keine wirklich gute Metrik.
5.

Ich benutze meinen Bildschirm im Hochformat und sehe 200 Codezeilen gleichzeitig.
Calmarius

und wenn ich keine Zeilenumbrüche verwende, um meine Zeilen aufzubrechen, kann ich eine 5000-Zeilen-Methode in einer einzelnen Zeile
codieren

1

Ich denke, TomToms Antwort kam meiner Meinung nach sehr nahe.

Ich finde mich immer mehr in zyklomatischer Komplexität als in Linien wieder.

Normalerweise strebe ich nicht mehr als eine Kontrollstruktur pro Methode an, mit Ausnahme der Anzahl der Schleifen, die für die Verarbeitung eines mehrdimensionalen Arrays erforderlich sind.

Manchmal setze ich einzeilige ifs in Switch Cases ein, weil dies aus irgendeinem Grund eher der Fall ist, als dass es hilft, wenn man es aufteilt.

Beachten Sie, dass ich keine Schutzlogik für diese Grenze zähle.


Es hat sich gezeigt, dass die zyklomatische Komplexität bei großen Mengen von echtem Produktionscode SEHR stark mit dem Roh-SLOC korreliert, was die Berechnung der zyklomatischen Komplexität zu einer totalen Verschwendung von Zeit, Energie und Taktzyklen macht.
John R. Strohm

@ JohnR.Strohm Ich spreche pro Methode, nicht insgesamt. Sicher, im Großen und Ganzen ist es sehr korreliert - die Frage ist, wie man diesen Code in Methoden aufteilt. 10 Methoden mit 100 Zeilen oder 100 Methoden mit 10 Zeilen haben immer noch den gleichen Gesamt-SLOC und die gleiche Komplexität, aber ersteres wird viel schwieriger zu bearbeiten sein.
Loren Pechtel

Ich auch. Die Korrelationsstudie befasste sich mit VIELEN Codes und VIELEN Routinen. (Es war eines der großen öffentlichen Repositories.)
John R. Strohm

-3

In OOP sind alle Dinge Objekt und es gibt diese Funktionen:

  1. Polymorphismus
  2. Abstraktion
  3. Erbe

Wenn Sie diese Regeln einhalten, sind Ihre Methoden normalerweise klein, es gibt jedoch keine Regeln für kleine oder sehr kleine Regeln (z. B. 2-3 Zeilen). Ein Vorteil einer kleinen Methode (kleine Einheit, z. B. Methode oder Funktion) sind:

  1. besser lesbar
  2. besser pflegen
  3. Fehler besser behoben
  4. ändert sich besser
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.