Ich bekomme zwei widersprüchliche Ansichten dazu. Einige Quellen sagen, es sollte weniger Methoden geben, um Methodenaufrufe zu reduzieren, aber eine andere Quelle sagt, dass das Schreiben einer kürzeren Methode gut ist, um JIT die Optimierung zu ermöglichen.C#, längere Methode oder kürzere Methode schreiben?
Also, welche Seite ist richtig?
Der Overhead des tatsächlichen Aufrufs der Methode ist in den meisten Fällen unbedeutend klein. Sie müssen sich niemals Sorgen machen, es sei denn, Sie können ein Problem auf dem Weg, das eine erneute Untersuchung des Problems erfordert, eindeutig identifizieren (Sie werden es nicht tun).
Es ist viel wichtiger, dass Ihr Code einfach, lesbar, modular, wartbar und änderbar ist. Methoden sollten nur eine Sache tun und Subdinge an andere Routinen delegieren. Dies bedeutet, dass Ihre Methoden so kurz wie möglich sein sollten, aber nicht kürzer. Sie werden weitaus mehr Leistungsvorteile sehen, wenn Sie Code haben, der weniger anfällig für Fehler und Bugs ist, weil er einfach ist, als wenn Sie versuchen, den Compiler oder die Laufzeit zu überlisten.
Die Quelle, die besagt, dass Methoden lang sein sollten, ist falsch, auf vielen Ebenen.
Keine, sollten Sie relativ kurze Methode Lesbarkeit erreichen.
Es gibt keine einfache Regel über die Funktionsgröße. Die Leitlinie sollte eine Funktion sein, sollte "eine Sache" tun. Das ist ein bisschen vage, wird aber einfacher mit Erfahrung. Kleine Funktionen führen in der Regel zur Lesbarkeit. Große sind gelegentlich notwendig.
Sorgen über den Overhead von Methodenaufrufen ist vorzeitige Optimierung.
Wie immer geht es darum, ein gutes Gleichgewicht zu finden. Das Wichtigste ist, dass die Methode nur eine Sache tut. Längere Methoden neigen dazu, mehr als eine Sache zu tun.
Zunächst sollten Sie die Leistung auf der Ebene der Anzahl der Methoden auf keinen Fall mikrooptimieren. Sie werden wahrscheinlich keinen messbaren Leistungsvorteil erhalten. Nur wenn Sie eine Methode haben, die millionenfach in einer engen Schleife aufgerufen wird, könnte es eine Idee sein - aber beginnen Sie nicht damit, diese zu optimieren, bevor Sie sie brauchen.
Sie sollten sich an kurze prägnante Methoden halten, die eine Sache tun, die die Absicht der Methode klar macht. Dadurch erhalten Sie leichter lesbaren Code, der leichter zu verstehen ist und die Wiederverwendung von Code fördert.
Das beste einzelne Kriterium, um Sie in Sizing-Methoden zu führen, ist halten sie gut testbar. Wenn Sie jede einzelne Methode gründlich testen können (und tatsächlich TUN! -), ist Ihr Code wahrscheinlich ziemlich gut; Wenn Sie beim Testen sparen, ist Ihr Code bestenfalls mittelmäßig. Wenn es schwierig ist, eine Methode gründlich zu testen, dann ist diese Methode wahrscheinlich "zu groß" - zu viele Dinge zu tun und daher auch schwerer zu lesen und zu warten (sowie schlecht getestet und daher ein wahrer Hafen für Fehler).
Die wichtigsten Kosten, die beim Schreiben von Code berücksichtigt werden müssen, sind Wartbarkeit. Sie verbringen viel, viel mehr Zeit, eine Anwendung zu behalten und Fehler zu beheben, als Sie jemals Leistungsprobleme beheben werden.
In diesem Fall sind die fast sicher unbedeutenden Kosten des Aufrufs einer Methode im Vergleich zu den Kosten für die Aufrechterhaltung einer großen unhandlichen Methode unglaublich gering. Kleine prägnante Methoden sind einfacher zu pflegen und zu verstehen. Darüber hinaus haben die Kosten für den Aufruf der Methode mit hoher Wahrscheinlichkeit keine wesentlichen Auswirkungen auf die Leistung Ihrer Anwendung. Und wenn dies der Fall ist, können Sie dies nur mithilfe eines Profilers sicherstellen. Entwickler sind bekanntlich schlecht darin, Leistungsprobleme vorher zu identifizieren.
Sobald ein Leistungsproblem erkannt wurde, können diese leicht behoben werden. Eine Methode zu erstellen oder, was noch wichtiger ist, eine Code-Basis, die wartbar ist, sind viel höhere Kosten.
Persönlich habe ich keine Angst vor langen Methoden, solange die Person, die sie schreibt, sie gut schreibt (jedes Stück Unteraufgabe getrennt durch 2 Zeilenumbrüche und einen netten Kommentar davor usw.) Auch die Identität ist sehr wichtig.). Tatsächlich bevorzuge ich sie sogar oft (z. B. wenn Code geschrieben wird, der Dinge in einer bestimmten Reihenfolge mit sequenzieller Logik ausführt).
Auch ich verstehe wirklich nicht, warum das Brechen einer langen Methode in 100 Stücke die Lesbarkeit verbessern wird (wie andere vorschlagen). Nur das Gegenteil. Sie werden nur am Ende des Spiels springen und Code-Teile in Ihrem Speicher behalten, nur um ein vollständiges Bild davon zu bekommen, was in Ihrem Code vor sich geht. Kombinieren Sie das mit möglichem Mangel an Kommentaren, schlechten Funktionsnamen, vielen ähnlichen Funktionsnamen und Sie haben das perfekte Rezept für Chaos. Sie könnten auch das andere Ende gehen, während Sie versuchen, die Größe der Methoden zu reduzieren: um VIELE Klassen und VIELE Funktionen zu erstellen, von denen jede VIELE Parameter annehmen kann. Ich denke nicht, dass dies auch die Lesbarkeit verbessert (besonders für einen Anfänger zu einem Projekt, das keine Ahnung hat, was jede Klasse/Methode macht).
Und die Forderung, dass "eine Funktion 'eine Sache' machen sollte" ist sehr subjektiv. "Eine Sache" kann eine Variable um eins erhöhen, um eine Menge Arbeit für das "gleiche Ding" zu tun.
Meine Regel ist nur Wiederverwendbarkeit: Der gleiche Code sollte an vielen Stellen nicht oft vorkommen. Wenn dies der Fall ist, benötigen Sie eine neue Funktion. Der ganze Rest ist nur philosophisches Gespräch. In einer Frage von "warum machen Sie Ihre Methoden so groß" antworte ich, "warum nicht, wenn der Code einfach ist?".
(nur meine Meinung - down-Abstimmung so viel wie Sie möchten)