Refaktorierung von Methoden

Question

Wie viele Codezeilen kann eine Methode mit einem guten Design haben, bevor man das Design verbessern muss?

Answer 1

Die Anzahl der Codezeilen ist ein unvollständiger Maßstab für das Refactoring. Zyklomatische Komplexität sollte in Verbindung mit LOC als guter Anhaltspunkt für den Zeitpunkt des Refactorings verwendet werden.

Ein angemessener Leitfaden ist

LOC > 80 || CC > 10 == "Time to refactor"

Die Chancen stehen gut, dass Sie eine zyklomatische Komplexität > 10 erreichen, lange bevor Sie 80 Codezeilen erreichen.

Natürlich gibt es noch eine ganze Reihe anderer Kennzahlen zu berücksichtigen:

1. Afferente Kopplung: Wie viele Methoden hängen von dieser Methode ab?
2. Efferente Kopplung: Auf wie viele Methoden stützt sich diese Methode?
3. Anzahl der Parameter
4. Anzahl der verwendeten Varialbes

Man kann ziemlich in die Tiefe gehen, aber all das bedeutet, dass die Entscheidung, wann ein Refactoring durchgeführt werden soll, nicht mit einer pauschalen Regel getroffen werden kann, wie "Du sollst nicht mehr als 40 Zeilen in einer Methode haben!"

Answer 2

Es gibt keine anerkannte Regel. Er sollte so einfach wie möglich zu lesen sein. Wenn das bedeutet, dass man 5 Zeilen eines 10-zeiligen Blocks in eine eigene Methode packen muss, dann soll es so sein. Aber manchmal kann es auch gut sein, 50-zeilige Methoden zu haben. Tun Sie einfach das, was Sie in 6 Monaten am besten verstehen werden.

Answer 3

Das hängt davon ab, was die Methode bewirkt. Es ist ein schmaler Grat zwischen dem Schreiben von zu wenigen und zu vielen Methoden, und vieles davon ist eine Frage des persönlichen Geschmacks.

Meine Meinung:

• 50 Zeilen sind zu lang für eine Methode. Ich denke, dass auch Methoden, die kürzer sind, oft zu lang sind, aber das ist meine Obergrenze für die Methodenlänge.
• Methoden sollten so geschrieben werden, dass sie mehr als einmal verwendet werden. Refaktorieren Sie nicht, um eine bestehende Methode zu verkürzen, sondern um wiederverwendbare Methoden zu erstellen, von denen andere Methoden profitieren können.

Es gibt keine willkürlichen Grenzen für die Länge des Codes, den eine Methode haben kann, bevor sie umgestaltet werden muss. Wenn sich eine Methode jedoch "zu lang" anfühlt, ist das in der Regel ein Zeichen dafür, dass Sie etwas falsch machen.

Answer 4

Nicht als Regel, sondern als Heuristik: Wenn eine Methode mehr als 25 Zeilen umfasst, überprüfe ich sie noch einmal, um zu sehen, ob ich sie in einfachere Komponenten aufteilen kann.

Das soll nicht heißen, dass Methoden mit mehr als 25 Zeilen nie gut konzipiert sind oder dass kürzere Methoden immer besser sind als längere. Es ist nur eine gute Heuristik, die man befolgen sollte.

Answer 5

So viele, wie nötig sind, um die einzige Aufgabe, die diese Methode erfüllt, logisch und eindeutig auszuführen.

Im Ernst: Es gibt keinen Maßstab. Im Allgemeinen möchten die Leute eine ganze Methode auf einer Seite auf ihrem Monitor sehen können, das ist also eine Sache, die man berücksichtigen sollte. Aber die Zeilenzahl ist nicht der primäre Indikator für logische Probleme. Zu viele Entwickler haben den Code verschleiert und die künftige Unterstützung erschwert, indem sie versucht haben, ihn in so wenige Zeilen wie möglich zu packen.

Gegen 1.000 Zeilen Code in einer einzigen Methode ist an sich nichts einzuwenden, wenn dies notwendig ist, um die Aufgabe logisch und eindeutig zu erfüllen. Es ist selten, und eine so lange Methode ist in der Regel ein Zeichen für Re-Factoring, aber es ist möglich. Dort es etwas, das von Natur aus falsch ist mit 1.000 Zeilen Spaghetti-Code, die alle unterschiedliche Dinge tun und auf seltsame Weise in einer einzigen Methode interagieren. Die Zeilenzahl ist nicht das Problem.