Best practices: Viele kleine Funktionen/Methoden, oder größere Funktionen mit logischen process-Komponenten inline?
Ist es besser zu schreiben, viele kleine Methoden (oder Funktionen), oder schreiben Sie ganz einfach die Logik/code dieser kleinen Prozesse, die rechts in den Ort, wo Sie genannt haben, die kleine Methode? Was ist mit den Abbruch-code in eine kleine Funktion, auch wenn vorerst nur von einer Stelle?
Wenn man die Wahl hängt von einigen Kriterien, was sind Sie, wie soll ein Programmierer eine gute Entscheidung?
Ich hoffe, die Antwort kann angewendet werden, im Allgemeinen in vielen Sprachen, aber wenn nötig, Antworten gegeben werden können, zu einer bestimmten Sprache oder Sprachen. Insbesondere, ich denke da an SQL (Funktionen, Regeln und gespeicherte Prozeduren), Perl, PHP, Javascript und Ruby.
- Splitting Dinge hilft, die Lesbarkeit des Codes. if( Convert.ToBoolean(row["IsActive"])) ist schlechter lesbar als "if(obj.IsActive)". 🙂
- Hm. Verwandte SOF-Frage: stackoverflow.com/questions/20981/...
- Ich persönlich mag es, wenn code, der hat sehr viele kleine Funktionen (1-3 Zeilen), die man nur von einem Ort (Sachen wie
int foo(){ return do_foo(); } int do_foo(){ /*actual code*/ }ist das Schlimmste, IMO), Dann, zu verstehen, die eigentliche nützliche Funktion aus, diese Stücke habe ich zu jagen, jeder Teilfunktion und es ist a) leicht, sich zu verirren in b) leicht aus den Augen verlieren mögliche Optimierungen. Ich würde sagen, wenn es schön passt in einen vollen Bildschirm und da gibt es kein Potenzial für die Wiederverwendung, nicht teilen es. - Der Hauptvorteil, die ich gefunden habe (zu machen Methoden kleiner) ist, dass Sie mehr sind, die leicht getestet werden, da Ihr Geltungsbereich/Verantwortung ist kleiner, und es passt "in den" menschlichen Verstand leichter.
- Es ist ein Gleichgewicht. Große monolithische Funktionen sind definitiv ein no-no, aber zu viele unnötige Mikro-Funktionen können Schaden Lesbarkeit auch-zumindest für mich tun Sie das.
- Ich völlig hören Sie, und ich respektiere, dass Sie ein Recht auf Ihre Meinung. Ich werde einfach mit Euch teilen, die ich verwendet, um zu denken, dass Art und Weise vor ein paar Jahren als gut, aber umgewandelt haben, über die kleine Methode camp. Ich habe nicht gefunden, dass es schwer zu durchqueren die Ausführung der Pfade in Dateien. grepping (oder gleichwertig) bekommt den job zu erledigen die meisten der Zeit. Ich habe gerade festgestellt, dass die Vorteile von die Dinge zu halten, klein zu sein, sehr konkret.
- Eines der Probleme mit der langen Methode der Programmierung ist, dass es temps Programmierer, vor allem Anfang Programmierer, um nicht zu schreiben, modularen code. Code sollte sich in den Klassen mit den Daten funktioniert es auf-manchmal auch als "Objekt-basierte Programmierung". Dies hilft bei der Reduzierung von code-Duplizierung. Lange Methode die Programmierung dazu neigt, eine Kultur zu schaffen, in denen Objekt-basierte Programmierung ist nicht betont.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich immer lange Pause Methoden in logische Stücke und versuchen, um kleinere Methoden aus Ihnen heraus. Ich weiß nicht normalerweise drehen Sie ein paar Zeilen in eine separate Methode, bis ich es brauche, in zwei verschiedenen Orten, aber manchmal Tue ich nur, um zu helfen Lesbarkeit, oder wenn ich will, um es zu testen in isolation.
Fowler ' s Refactoring ist alles über dieses Thema, und ich empfehle es.
Hier ist eine praktische Faustregel, die ich nutzen von Refactoring. Wenn ein code-Abschnitt, der hat ein Kommentar, ich konnte re-Wort in den Namen einer Methode, ziehen Sie es aus und machen es zu einem Methode.
Die Größe der Methode ist es, direkt mit seinercyclomatic complexity .
Sind die wichtigsten Vorteile, um die Größe der die Methode klein (das heißt die Aufteilung eine große Methode in mehrere kleinere Methoden), sind:
Wie immer kann man sagen: es hängt davon ab. Es ist mehr eine Frage der Benennung und Definition der Aufgabe, eine Methode. Jede Methode, die eine (nicht mehr) gut definierte Aufgabe und tun sollten Sie Sie vollständig. Der name der Methode sollte unbedingt die Aufgabe. Wenn Ihre Methode benannt ist DoAandB() kann es besser sein, dass verschiedene Methoden DoA() und DoB(). Wenn Sie brauchen Methoden wie setupTask, executeTask, FinishTask, kann es nützlich sein, Sie zu kombinieren.
Einige Punkte, die zeigen, dass eine Zusammenführung von verschiedenen Methoden können hilfreich sein:
Einige Punkte, die darauf hindeuten, dass ein splitup der Methode nützlich sein könnte:
Als Erklärung für die unit-test-argument: ich habe eine Methode, die noch einige Dinge, einschließlich IO. Die IO-Teil war sehr schwer zu testen, also habe ich darüber nachgedacht. Ich kam zu dem Schluss, dass meine Methode war 5 logischen und voneinander unabhängigen Schritten, und nur einer von Ihnen beteiligt sind die IO. So ich teilte meine Methode in 5 kleinere, vier von Ihnen waren einfach zu testen.
Kleine Methoden zu jeder Zeit.
Sind Sie selbst dokumentieren (er, wenn auch mit Namen)
Brechen Sie das problem in überschaubare Teile - Sie sind KeepingItSimple.
Können Sie verwenden, OO-Techniken, um leichter (und offensichtlich), plug-in-Verhalten. Die große Methode ist per definition mehr Verfahrensschritte und damit weniger flexibel.
Sind Sie unit-testbar. Dies ist der killer, man kann einfach nicht unit test einige große Methode, führt eine Last von Aufgaben
Etwas, was ich gelernt habe aus Dem Code Complete Buch:
implementieren Sie eine chunk(oder die Einheit oder die Aufgabe)
von Logik. Ob das erforderlich ist Panne
in sub-tasks, dann schreiben Sie eine
seperate Methode/Funktion für Sie
und Ruf Sie an.
name immer lang ist, dann versuche ich
untersuchen der Methode, um es zu sehen kann es
aufgegliedert in zwei Methoden.
Hoffe, das hilft
Mache ich jede Funktion ist eine Sache und eine Sache nur, und ich versuche, nicht zu brüten, zu viele Ebenen der Logik. Sobald Sie beginnen, Sie zu brechen, Ihren code nach unten in auch als - Funktionen, wird es viel einfacher zu Lesen, und praktisch selbsterklärend ist.
Ich finde, dass viele kleine Methoden macht den code leichter Lesen, verwalten und Debuggen.
Wenn ich lese, durch ein Gerät implementiert, dass einige business-Logik, das kann ich besser Folgen dem Fluss, wenn ich sehe, dass eine Reihe von Methodenaufrufen, die den Prozess beschreiben. Wenn ich Pflege darüber, wie die Methode implementiert wird, kann ich geh mal in den code.
Fühlt es sich wie mehr Arbeit, aber es spart letztendlich Zeit.
Es ist eine Kunst, ich denke, zu wissen, was zu Kapseln. Jeder hat einige geringfügige Meinungsverschiedenheiten. Wenn ich könnte man es in Worte ich würde sagen, dass jede Methode tun sollten, ein Ding, das beschrieben werden kann als eine komplette Aufgabe.
Einige Faustregeln:
Je größer die Methode, die schwerer zu testen und zu warten. Ich finde es viel einfacher zu verstehen, wie eine große Prozess funktioniert, wenn seine zerlegt in atomaren Schritten. Auch dies ist ein großer Erster Schritt, um Ihre Klassen erweiterbar. Können Sie diejenigen markieren, die einzelnen Schritte als virtuelle (für die Vererbung), oder verschieben Sie Sie in anderen Objekten (Komposition), so dass Ihre Anwendung Verhalten leichter anpassen.
Normalerweise gehe ich für die splitting-Funktionen in kleinere Funktionen, die jeweils eine einzelne, Atomare Aufgabe, aber nur, wenn die Funktion ist Komplex genug, um zu Gewähr es.
Diese Weise habe ich am Ende nicht mit mehreren Funktionen für einfache Aufgaben, und die Funktionen, die ich tun-Extrakt kann in der Regel an anderer Stelle verwendet werden, da Sie nicht versuchen zu erreichen, zu viel. Dies hilft auch unit-Tests als jede Funktion (logisch, atomic action) kann dann individuell geprüft werden.
Persönlich, lehne ich mich deutlich in die Richtung lieber mehr kleinere Methoden, aber nicht zu dem Punkt, religiös strebt die maximale Anzahl der Zeilen. Mein primäres Kriterium oder Ziel zu halten, ist mein code TROCKNEN. Die minute, die ich habe einen code-block, die ist doppelt vorhanden (ob im Geiste oder tatsächlich durch den text), auch wenn es vielleicht 2 oder 4 Zeilen lang, ich vertrocknen, dass code in eine separate Methode. Manchmal werde ich tun, im Voraus, wenn ich denke, es gibt eine gute chance, es wird wieder in der Zukunft verwendet.
Auf der anderen Seite, ich habe auch gehört, dass es argumentiert, dass, wenn Ihre break-off-Methode ist zu klein, im Rahmen eines Teams von Entwicklern, ein Teamkollege ist wahrscheinlich nicht zu wissen, über Ihre Methode, und Sie werden entweder schreiben, inline, oder schreiben, seine eigenen kleine Methode, die nicht die gleiche Sache. Dies ist zugegebenermaßen eine schlechte situation.
Einige auch versuchen zu argumentieren, dass es besser lesbar zu halten, Dinge, inline, so ein reader kann nur Lesen top-down, anstatt zu springen, um Methode, Definitionen, evtl. in mehreren Dateien. Ich persönlich glaube, dass die Existenz eines stack-trace macht das nicht viel von einem Problem.
Hängt es ein bisschen ... auf die Denkweise. Dennoch ist dies nicht eine subjektive Frage.
Die Antwort eher hängt tatsächlich davon ab, die sprachlichen Zusammenhang.
In einem Java/C#/C++ - Welt, wo die Menschen nach dem "Clean Code" - Schule, als Predigten von Robert Martin, dann: viele kleine Methoden sind der Weg zu gehen.
Einer Methode hat einen eindeutigen Namen, und nicht eine Sache. Eine Ebene der Verschachtelung, das ist es. Das beschränkt die Länge auf 3, 5, max 10 Zeilen.
Und ganz ehrlich: ich finde diese Art der Codierung absolut besser als alle anderen "Stil".
Der einzige Nachteil dieses Ansatzes ist, dass Sie am Ende mit vielen kleinen Methoden, so dass die Bestellung innerhalb einer Datei/Klasse kann zu einem Problem werden. Aber die Antwort ist die Verwendung eine anständige IDE, mit dem man leicht navigieren, vorwärts und wieder zurück.
So, das einzige "legitime" Grund für die Verwendung von "allen Sachen, geht in eine Methode/Funktion" ist, wenn dein ganzes team so funktioniert und lieber, dass Stil. Oder wenn Sie nicht verwenden können anständige tooling (aber dann navigieren, die große hässlich-Funktion wird nicht funktionieren).