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!
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;)
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:
Irgendwelche anderen Qualitätskriterien, die ich vermisst habe?
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.
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 .
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.
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.
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.
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.
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.
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.
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.