Wie lang sollten Funktionen / Methoden im Durchschnitt sein?

8

Wir haben alle übermäßig lange Methoden oder Funktionen gelesen, wo Ihre Augen bluten, wenn Sie die return -Anweisung erreichen. Wir haben auch diese One-Liner-Funktionen gesehen, die sinnlos erscheinen ...

Ich wollte nur fragen: Was ist Ihrer Meinung nach die beste durchschnittliche Länge für eine Funktion / Methode? Wenn Sie berücksichtigen, dass jede Sprache ihre eigenen Wege hat, können Sie in Ihrer Antwort angeben, auf welche Sie sich beziehen. Danke!

    
Manuel Aráoz 23.07.2009, 07:34
quelle

11 Antworten

16

Es gibt keinen Grund, die "durchschnittliche Funktionslänge" zu diskutieren. Sie müssen die Faustregel verwenden. Funktion / Methode muss eine sehr genaue Funktionalität haben, die durch ihren Namen repräsentiert werden sollte. Wenn Sie nicht definieren können, was es in seinem Namen tut, sollten Sie es teilen. Aber die Länge kann variieren, da einige sehr bestimmte Aufgaben ziemlich viel Code erfordern.

Und wie Sie gesagt haben, wenn Sie einige Funktionen betrachten, bluten Ihre Augen. Wenn sie bluten, stimmt etwas nicht mit der Funktion überein;)

    
leafnode 23.07.2009, 07:41
quelle
14

Es ist nicht so sehr die Länge, die eine gute Methodenimplementierung macht. Länge ist nur ein Aspekt unter anderem bei der Beurteilung der Qualität einer Methodenimplementierung:

  • Abstraktionsgrad: Der Code in einer Methode sollte eine homogene Abstraktionsebene beibehalten. Ich meine, es kann Ihren Kopf drehen, wenn Sie eine Methode mit Calls auf sehr hohem Niveau lesen müssen, die zwischen Blöcken verteilt sind, die grundlegende Bitverschiebungen, String-Verarbeitung usw. ausführen. Indem Sie dieser Regel folgen, entfernen Sie Distraktionen für diejenigen, die versuchen zu begreifen Methode tut.
  • Formatierung: Der Code muss immer formatiert sein, um die Lesbarkeit zu optimieren. Wenn Sie einen Block zu einer bestehenden Methode hinzufügen, richten Sie ihn an den entsprechenden Code aus. Lege leere Zeilen zwischen semantisch verbundene Blöcke. Respektieren Sie die Codierungskonventionen des Teams.
  • Kommentare: Zögern Sie nicht zu kommentieren was Ihr Code tut. Das ist bereits im Code geschrieben. Wenn du Kommentare hinzufügst, dann konzentriere dich auf warum es auf diese Weise gemacht wurde.
  • Fokus: Eine Methode sollte sich auf eine bestimmte Aufgabe konzentrieren. Sie sollten die Implementierung in einem zusammenfassenden Satz beschreiben können.
  • Länge: Zögern Sie nicht, eine Methode länger als eine Monitorseite zu erstellen.

Irgendwelche anderen Qualitätskriterien, die ich vermisst habe?

    
mkoeller 23.07.2009 08:17
quelle
9

Eine Funktion sollte niemals länger als ein Bildschirm sein.

Die Funktionen sollten so lang sein wie deine Aufmerksamkeit, so dass es möglich ist, die ganze Bedeutung davon in deinem Kopf zu behalten. Ziel sollte es sein, die Problemlösung so klar wie möglich auszudrücken.

Es ist eine gute Idee, eine Faustregel über die maximale Länge zu haben, da dies einen guten Hinweis darauf gibt, wann Sie nicht genug Klarheit erreicht haben könnten. Meiner Meinung nach kann man ziemlich sicher sein, dass etwas länger als ein Bildschirmvoll wahrscheinlich nicht klar genug ist, also verwende ich das als Faustregel, aber ich bemühe mich, Funktionen so kurz und so kurz wie möglich zu machen.

Eine Zeile Funktionen sind vollkommen akzeptabel, wenn sie den Code klarer machen, d. h. wenn der Code darin nicht schon offensichtlich liest, was die Funktion tut.

    
Joakim Lundborg 23.07.2009 07:57
quelle
3

Wie Abraham Lincoln sagte, als er gefragt wurde, wie lange das Bein eines Mannes sein sollte, "lang genug, um den Boden zu erreichen".

Jede Funktion / Methode wird anders sein.

    
jlarson 23.07.2009 07:41
quelle
2

Ich denke, die Leute von Object Mentor haben eine Weile über dieses Thema nachgedacht. Sie haben Eine ähnliche Frage wurde vor einigen Jahren gestellt .

Sie können sich dieses großartige Gespräch ansehen, Clean Code III: Funktionen .

    
nephewtom 21.09.2010 13:18
quelle
1

Kürzere Methoden mit einer Vielzahl anderer Methodenaufrufe, nur um den Code in einer bestimmten Methode zu reduzieren, bedeuten nicht notwendigerweise eine "bessere" Methode.

Worum Sie sich kümmern sollten, ist nicht die Länge, sondern die Komplexität, Lesbarkeit, Verwendbarkeit und Skalierbarkeit der Methode und ob der Code in eine einfachere, leichter lesbare, weniger komplexe Version umgestaltet werden kann.

    
Sev 23.07.2009 07:41
quelle
1

Für mich ist es sehr schwer, wenn eine Funktion länger ist als eine gedruckte Seite. Ich mag auch nicht, Linie in einen Ausdruck einzuwickeln. Macht dies mich altmodisch oder gebe ich mein Alter weg - Druckcode?

Ich würde auch sagen, dass wenn der Name einer aufgerufenen Funktion in meinem Code mir nicht sagt, was die Funktion macht, es oft umständlicher ist, durch mehrere Funktionen zu springen, um herauszufinden, was getan wird. Das erinnert mich an die guten alten COBOL-Tage, wo wir Code ausgedruckt, auf dem Flur verteilt haben und vier Jungs versuchten, allen GOTOs zu folgen. (Jetzt weißt du definitiv, dass ich schon eine Weile hier bin.)

Es ist also eine Balance zwischen Länge und guten Namenskonventionen.

    
Ralph M. Rickenbach 23.07.2009 07:46
quelle
1

Der Versuch, eine durchschnittliche Methodenlänge zu definieren, ist nur so, als würde man sagen, dass mehr Codezeilen eine bessere Produktivität bedeuten.

Methodenlänge ist eine bedeutungslose Zahl. Sie messen die Qualität einer Methode anhand ihrer Spezifität, Effizienz, Robustheit und Lesbarkeit. nicht wie viele Zeilen es gibt. Die Anzahl der Zeilen wird noch bedeutungsloser, wenn Sie verschiedene Codierungsstile in Betracht ziehen - einige Leute mögen einfach eine Menge Leerzeichen.

Wenn Sie wirklich wirklich eine Richtlinie wünschen, nehmen Sie einfach automatisch an, dass jede Methode, die länger als eine Seite ist (oder zwei (je nach Ihrer Auflösung), wahrscheinlich zu lang ist.

    
aberrant80 23.07.2009 07:48
quelle
1

Das Einkapseln von Komplexität ist eine der wichtigsten Funktionen von Funktionen. Es weist den Leser darauf hin, dass dieses Stück Code nichts mit diesem Teil des Codes zu tun haben kann, außer durch Parameter- / Ergebniswerte. Komplexität ist auch der Grund, warum Nebenwirkungen generell vermieden werden sollten.

Natürlich sind kleine Funktionen leichter zu lesen, aber wenn es keine Komplexität gibt, z.B. Setzen Sie 200 Optionen in einem Konfigurationsobjekt, dann haben Sie auf jeden Fall eine Funktion mit 200 Zeilen.

Das Teilen von Funktionen mit geringer Komplexität kann die Lesbarkeit für diese Funktion erhöhen, aber auch die globale Komplexität etwas erhöhen.

    
Inshallah 23.07.2009 08:12
quelle
1

Meine Regel ist: Es sollte durch kurze Inspektion (sagen wir, 30 Sekunden oder weniger) offensichtlich sein, dass der Name der Funktion ihrer Implementierung entspricht, vorausgesetzt, dass alle Funktionen, die sie verwendet, Implementierungen haben, die ihren Namen entsprechen.

Praktisch bedeutet dies, dass meine Funktionen ziemlich kurz sind. Einige von ihnen sind einfache Definitionen. Als pathologisches Beispiel:

%Vor%

Wenn AdditiveInverse und Negate unterschiedliche Konzepte in meinem Kopf sind und zufällig in der realen Welt zusammenfallen. Es ist nichts falsch mit einer Teenie-Funktion, wenn es ein neues Konzept einführt.

Ich habe festgestellt, dass diese Faustregel mit einem ziemlich hohen Programmierstil einfacher zu ziehen ist. Speicherverwaltung, separate Indexübergabe usw. behindern die Durchführbarkeit. Ich finde, dass funktionale Sprachen diesem Stil besonders zugänglich sind: Es ist eine unzerstörbare Richtlinie für mich, wenn ich Haskell schreibe, und eine lose Heuristik, wenn ich C # schreibe.

    
luqui 23.07.2009 11:52
quelle
1

Bevorzugen Sie kleine und fokussierte Funktionen.

Wir erkennen, dass lange Funktionen manchmal angemessen sind, so dass keine feste Grenze für die Länge der Funktionen gesetzt wird. Wenn eine Funktion mehr als 40 Zeilen überschreitet, überlegen Sie, ob sie aufgelöst werden kann, ohne die Struktur des Programms zu beeinträchtigen.

Auch wenn Ihre lange Funktion jetzt perfekt funktioniert, kann jemand, der sie in einigen Monaten modifiziert, neues Verhalten hinzufügen. Dies könnte zu Fehlern führen, die schwer zu finden sind. Wenn Sie Ihre Funktionen kurz und einfach halten, können andere Ihren Code einfacher lesen und ändern.

Sie können lange und komplizierte Funktionen finden, wenn Sie mit etwas Code arbeiten. Lassen Sie sich nicht einschüchtern, indem Sie bestehenden Code modifizieren: Wenn sich die Arbeit mit einer solchen Funktion als schwierig erweist, finden Sie Fehler, die schwer zu debuggen sind, oder Sie möchten einen Teil davon in mehreren verschiedenen Kontexten verwenden und mehr überschaubare Stücke.

Quelle

Obwohl ich dem zustimme, glaube ich, dass Sie atomare Funktionen schreiben sollten. Das bedeutet: Sie sollten Funktionen so klein wie möglich schreiben und dabei einen bestimmten Funktionsnamen beibehalten. Aber machen Sie sich nicht verrückt, weil Sie eine Menge Funktionen haben, die nur eine Zeile sind.

Ich glaube auch, dass Sie beim Schreiben von Funktionen nicht viele leere neue Zeilen haben sollten, um einen Codeblock anzugeben, der etwas anderes tut. Wenn Sie alle 30 Zeilen eine neue Zeile haben, dann können diese 30 Zeilen möglicherweise eine neue Funktion bilden. Oder vielleicht nicht. Vielleicht sind diese 30 Zeilen so spezifisch für den Zweck des Programms, dass Sie es nicht woanders in einem anderen Programm verwenden können.

Denken Sie an die Zukunft: Erstellen Sie Funktionen, die Sie auch in Ihren anderen Projekten verwenden können. Generische Funktionen erstellen Also, wenn Sie Funktionen schreiben, versuchen Sie, sie generisch zu machen, aber nicht zu viel, weil es Ihnen viel Zeit kosten kann, manchmal, um sie generisch zu machen und Sie haben ein Programm zu beenden, richtig? Halten Sie es einfach, wie es der Google-Codingstil empfiehlt.

    
Platwn Ace 14.01.2017 18:10
quelle

Tags und Links