Codierungsrichtlinie: Methoden sollten nicht mehr als 7 Anweisungen enthalten?

Ich habe die AvSol-Codierungsrichtlinien für C # durchgesehen und bin mit fast allem einverstanden, bin aber sehr gespannt, was andere von einer bestimmten Regel halten.

AV1500

Methoden sollten 7 Anweisungen nicht überschreiten Eine Methode, die mehr als 7 Anweisungen erfordert, tut zu viel oder hat zu viele Verantwortlichkeiten. Außerdem muss der menschliche Verstand die genauen Aussagen analysieren, um zu verstehen, was der Code tut. Teilen Sie es in mehrere kleine und fokussierte Methoden mit selbsterklärenden Namen auf.

Befolgen die meisten von Ihnen diese Regel? Auch wenn Sie bei der Erstellung einer neuen Methode (Ihr Code ist immer noch DRY ) nur wenig sparen müssen, abgesehen von einer deutlich verbesserten Lesbarkeit? Und ist Ihre Zahl immer noch so niedrig wie 7? Ich würde eher gegen 10 tendieren.

Ich sage nicht, dass ich überall gegen diese Regel verstoße - im Gegenteil, meine Methoden sind zu 95% klein und konzentriert, aber ich sage, dass Sie niemals gegen diese Regel verstoßen sollten, hat mich wirklich umgehauen.

Ich möchte wirklich nur wissen, was jeder davon hält, NIEMALS gegen diese Regel zu verstoßen. Aber ich denke, Sie würden Probleme haben, eine Codebasis zu finden, die dies nicht tut.

Dies ist ein "Standardgeruch" für mich. Wann immer ich Codierungsstandards mit bestimmten Grenzen darin sehe, mache ich mir Sorgen. Sie stoßen fast immer auf einen Fall, in dem eine Methode größer sein muss als es der Standard zulässt (ob es sich um die Länge / Anzahl der Linien, die Anzahl der Variablen, die Anzahl der Austrittspunkte usw. handelt). Standards sollten eher Richtlinien sein und ausreichend Spielraum für ein gutes Urteilsvermögen lassen. Versteht mich nicht falsch, es ist gut, Standards zu haben, aber sie sollten nicht zu "Mikromanagement durch Proxy" werden.

Es ist normalerweise eine gute Idee, Dinge in kleine Methoden aufzuteilen. Aber das Wichtigste ist, Dinge dort aufzuteilen, wo es Sinn macht.

Wenn es keinen Sinn macht, sich zu trennen, dann trennen Sie sich nicht. Dies ist häufig bei einigen Prozeduren oder GUI-Code der Fall.

Steve McConnell erklärte in Code Complete, dass Sie mit kurzen Methoden nicht immer produktiver sind. Wenn Sie aufteilen, wenn es keinen Sinn ergibt, fügen Sie dem Code Komplexität hinzu, ohne dass dies von Vorteil ist.

Wie immer bei Richtlinien ist es wichtig, sich daran zu erinnern, warum die Einschränkungen bestehen, damit Sie lernen können, wenn sie nicht zutreffen. In den meisten Codes sind die Methoden kurz, oder Sie haben wahrscheinlich ein Problem mit DRY oder der Trennung von Bedenken . Aber wenn nicht, dann gut.

Dies sollte als Faustregel angesehen werden.

Dinge wie "Nicht mehr als 80 (100.120) Textspalten", "Ein Austrittspunkt pro Methode", "Nicht mehr als 2 Verschachtelungsebenen", würde ich Schwellenwerte für Indikatoren des Codegeruchs nennen. Wenn Sie sie gelegentlich verletzen, bedeutet dies nicht unbedingt, dass der Code schlecht ist. Wenn Sie feststellen, dass Sie sie ständig verletzen, riecht etwas im Code und Sie möchten vielleicht eine Pause einlegen und Ihren Ansatz überdenken.

Für mich sind die wichtigsten Kriterien: "Ist dieser Code verständlich?", "Ist er sich wiederholend?", "Ist er an logischen Stellen aufgeteilt?", "Ist er lose miteinander verbunden?" Es gibt noch ein paar mehr, aber ich denke, die Grundidee lässt sich zusammenfassen, wenn man sich an Donald Knuths Rat erinnert: "Programme sind dazu gedacht, von Menschen gelesen zu werden und nur gelegentlich von Computern ausgeführt zu werden."

Ich habe mir nie die Zeit genommen, die Anzahl der Anweisungen in meinen Methoden tatsächlich zu zählen, aber ich bemühe mich, Methoden zu schreiben, die sauber einen einzigen, klaren Zweck erfüllen. Solange Ihr Code sauber und lesbar ist und den Grundsätzen von DRY und Single Responsibility folgt , haben Sie wahrscheinlich Ihre Arbeit getan. Ich denke, dass eine willkürliche Aufteilung einer Methode, nur um die Beschränkung auf sieben Anweisungen zu erzwingen, Ihren Code weniger lesbar / wartbar machen könnte.

Es ist ungefähr

Diese Art von Regeln sollten nicht zu wörtlich genommen werden. Sie hätten sagen können " Methoden sollten kurz sein ". Einige Leute hätten dies jedoch als "weniger als 1 Seite" und andere als "höchstens 2 Zeilen" interpretiert.

Ich würde annehmen, dass sie "7 Aussagen" sagten, um Ihnen eine grobe Vorstellung zu geben (obwohl ich denke, dass sie "ungefähr 7" sagten sollten). Wenn Sie ab und zu 9 brauchen, schwitzen Sie nicht. Aber wenn Sie 20 erreichen, wissen Sie, dass Sie für diese Regel nicht im richtigen Stadion sind.

7 ist eine völlig willkürliche Zahl ohne jegliche Bedeutung.

Die zyklomatische Komplexität ist ein größeres Problem als die Anzahl der Aussagen. Ich habe Code gesehen, der Hunderte von Anweisungen in einer einzigen Methode enthielt (was ich für schrecklich hielt), aber er hatte eine zyklomatische Komplexität von 1 und tat wirklich nur 1 Sache. Es gab nur viele Stufen. Wir haben darüber gesprochen, es in kleinere Methoden aufzuteilen, aber diese Methoden würden nur von dieser einen Methode aufgerufen.

Das ist zwar ein ziemlich extremer Fall, aber der Punkt ist, dass Sie den Code DRY und eine geringe zyklomatische Komplexität beibehalten müssen. Das ist wichtiger als die Anzahl der Zeilen in einer Methode.

Nehmen Sie zum Beispiel eine switch / case-Anweisung. Wenn Sie mehr als 7 mögliche Werte haben, müssen Sie die Auswertung in mehrere Methoden aufteilen? Natürlich nicht, das wäre albern.

Wenn Sie den Code künstlich in mehrere Methoden aufteilen, um die Anzahl der Anweisungen unter 7 zu halten, wird der Code nur noch schlimmer.

Die Richtlinie sollte lauten: Jede Methode sollte 1 Aktion ausführen und Ihren Code TROCKEN halten.

Nun, es kommt ein bisschen darauf an. Ich schreibe viel Code, der auf Datenbanken zugreift. Der Kesselschildcode für die Ausnahmebehandlung umfasst in vielen Fällen mehr als sieben Anweisungen. Ich würde sagen, die beste Richtlinie ist, sicherzustellen, dass Ihre Funktion einen Zweck hat

Alles ist ein Kompromiss. Das Problem bei dem vorgeschlagenen Ansatz - das Umgestalten in mehrere Methoden und Klassen, so dass jede Methode kurz ist - besteht darin, dass es aus unterschiedlichen Gründen zu unlesbarem Code führt, wenn es zu extremen Ergebnissen kommt.

Stellen Sie sich eine Methode vor foo(), die 7 Dinge tut. Sie könnten argumentieren, dass 7 Dinge zu viel sind. Vielleicht haben Sie in vielen Fällen recht. Andererseits könnten diese 7 Dinge eng miteinander verbunden sein; die Logik kann glatt fließen und wie Prosa lesen; Möglicherweise haben Sie keine Probleme, es zu verstehen, wenn Sie es tatsächlich benötigen. Was viel schlimmer sein könnte, ist, diese 7 Dinge über einen großen Quellbaum verteilt zu haben, so dass Sie, wenn Sie sich das ansehen foo(), keine Ahnung haben, was es tut, ohne an 7 verschiedenen Orten nachzuschauen.

Viele Leute haben solche Regeln im Kopf, und das Ergebnis ist das, was ich als OO-Spaghetti bezeichne. Alles ist ordentlich, in einer eigenen kleinen Methode oder Klasse verpackt, mit atomaren kleinen Mikrotransaktionen, die an jedem Ort stattfinden. Aber es ist unmöglich, auf eine solche Codebasis zu kommen und zu wissen, was sie tut. Du wirst verloren.

Es ist keine schlechte Richtlinie. Ich habe es nie bereut, Methoden und Klassen aufgeteilt zu haben (ich habe nie festgestellt, dass ich zu viele hatte), solange sie gut genug gruppiert und miteinander verbunden sind.

Der Trick besteht darin, es NICHT vertikal zu teilen (Kneifen Sie einfach eine Methode an einem Punkt ab und beginnen Sie eine neue). Der Trick besteht, wie beim Unit-Testen, darin, eine solche Regel von Anfang an im Hinterkopf zu behalten, damit Sie tatsächlich besser entwerfen und 3 oder 4 Anweisungen in der Mitte der Methode an eine andere Methode weitergeben, da ein Methodenaufruf beschreibt, was Sie besser machen als Diese 3 oder 4 Anweisungen in der Mitte Ihres Codes.

Diese Art der Aufteilung kann, auch wenn sie willkürlich ist und nur einmal verwendet wird, später aufgrund einer neuen Klarheit des Codes zu besseren Umgestaltungen führen. Dies gilt auch für kleinere Klassen.

Stellen Sie sich vor, Sie würden Unit-Tests durchführen. Wenn Sie versuchen, Unit-Tests nachträglich hinzuzufügen, ist dies schwierig und manchmal unmöglich, aber wenn Sie es von Anfang an entwerfen, verbessert es tatsächlich Ihren gesamten Code.

Zusammenfassung? Wenn Sie den Design-Geruch von "Weniger als 7 Anweisungen verwenden" mit dem Code-Geruch von "Ich habe mehr als 7 Anweisungen verwendet" vergleichen, sollten Sie den Code-Geruch beseitigen.

Beeindruckend! Ich hätte nie erwartet, eine so intensive Diskussion über eine einfache Richtlinie zu finden, die ungefähr besagt, dass Ihre Methoden sehr klein sein sollten. Da es sich immer um Entwickler handelt, deren Richtlinien explizit sein sollen, habe ich 7 gewählt, da dies nach einer schönen Schwelle klang.

Einige von Ihnen haben den Haftungsausschluss bereits am Anfang des Dokuments zitiert. Dieses Dokument stellt jedoch eine Sammlung von Richtlinien dar, die Ihnen helfen sollen, besseren Code zu schreiben und bessere Systeme zu entwerfen. Ich habe nie gesagt, dass irgendetwas eine Regel sein sollte, obwohl eine Richtlinie als Stufe 1 markiert ist. Diese Stufen sind einfach die kollektive Meinung der vielen Menschen, die dieses Dokument seit einer Weile verwenden.

Ich habe auch nie behauptet, ein Experte zu sein. Aber ich bin jetzt seit 15 Jahren in diesem Beruf, mit ungefähr 4 Jahren C ++ - Erfahrung und 11 Jahren C # -Erfahrung. Es basierte ursprünglich auf Industrial Strength C ++, aber ich habe es seitdem mit Beiträgen der Community verfeinert.

Ungeachtet dessen war der Punkt, den ich ansprechen wollte, der, dass Sie weiter für sich selbst denken sollten. Wenn Sie der Meinung sind, dass der Leitfaden mit den 7 Aussagen nicht nützlich ist, machen Sie ihn einfach länger. Mist, ich verstoße sogar ab und zu gegen diese Richtlinie. Ich verstoße nur bewusst dagegen und akzeptiere die Konsequenzen.

Erstens: Es ist eine Richtlinie, keine Regel. Es wird als Richtlinie bezeichnet, also behandeln Sie es bitte als solche. Dies impliziert, dass auch Ihr eigenes Urteil erforderlich ist (wie immer)

Abgesehen davon kann ich mir viele Beispiele für guten Code vorstellen, die diese Einschränkung nicht einhalten. Obwohl es nur eine Richtlinie ist, ist es eine schlechte.

Ich stimme der obigen Aussage zu. Dies ist nur eine Richtlinie, und in einer perfekten Welt wäre alles ein Objekt, das in jedem Programm wiederverwendet wird, und die Welt wäre ein wunderschöner Ort. Es ist nicht immer wahr und manchmal würde das zu viel Aufwand oder verschwendeten Ressourcen führen. Das müssen Sie auch berücksichtigen.

Ziemlich dumm, wenn Sie der Mischung Ausnahmebehandlung hinzufügen.

Nach "try, catch, finally" stehen Ihnen pro Methode vier Anweisungen zur Verfügung!

Betrachten Sie auch eine Methode "validateForm" für ein Formular mit 20 Feldern, selbst wenn Sie alle Einzelvalidierungen in separaten Methoden behandeln, müssen Sie noch 20 Feldvalidierungsmethoden aufrufen. Nach diesen Richtlinien würden Sie mit einer sinnlosen Aufteilung wie "validateTopOfScreen", "validateMiddleOfScreen" und "validateBottomOfScreen" enden.

Die Frage ist, "Regeln" mit "Richtlinien" in Einklang zu bringen. Regeln sind dazu gedacht, eingehalten zu werden - Richtlinien sind Ratschläge, die Sie veranlassen sollen, zu überlegen, was Sie tun und ob es wirklich besser gemacht werden könnte.

Ich würde sagen, dass im Durchschnitt die meisten Programmierungen wahrscheinlich durch das Befolgen von Richtlinien verbessert werden, aber es wird immer Fälle geben, in denen das Befolgen der Richtlinien dogmatisch mehr Probleme verursacht, als sie lösen sollen. Deshalb werden sie nicht als Regeln, sondern als Richtlinien dargestellt.

Ein früherer Antworter hat gezeigt, dass die Verfasser der Richtlinien niemals beabsichtigten, sie dogmatisch anzuwenden, und in ihr Dokument entsprechende Aussagen aufgenommen.

Ich bin mit den obigen Kommentaren einverstanden. 7 ist für mich willkürlich und kann in einigen Sprachen nützlich sein, in denen Ruby vorkommt, aber für Sprachen wie C #, Java, C ++ bezweifle ich diese "7-Zeilen" -Konvention. Lassen Sie mich Ihnen ein Beispiel geben. Meine aktuelle Anwendung hat 22 Textfelder und ich führe die serverseitige Validierung durch. Die Methode heißt validateInput () und meine Vorliebe ist es, alle Felder in einer Methode selbst zu validieren, es sei denn, ich habe etwas Komplexes wie checkEmailFormat () validiert. Mein validateInput-Methodencode besteht also im Grunde aus 108 Zeilen mit gelegentlichen Aufrufen zur komplexen Validierung.

Stellen Sie sich nun vor, ich hätte 25 Methoden aufgerufen, um jedes Feld zu validieren. Wenn ein neuer Entwickler hinzukommt, muss er in die Hauptmethode ein- und aussteigen, um durch 25 Methoden zu springen, die wiederum einige andere aufrufen könnten. Er muss sich in großen Projekten verirren.

Was ich wirklich tue, um meinen Code klar zu machen, ist saubere Kommentare, die im Grunde sagen, was diese 4 Zeilen ex - tun.

validateInput (UserObj user) {

// Vorname validieren ....... ......

// Nachname validieren ...... ......

// E-Mail validieren ..... // zu komplex, um das E-Mail-Format zu überprüfen. regulärer Ausdruck checkEmailFormat (); .... .....

und so weiter.. }

Schlechte Regel. Wie können die meisten Methoden mit Code für die Ausnahmebehandlung, das Festlegen von Datenbankfeldern und die Validierung unter sieben Anweisungen liegen? Sollten wir niemals Inline-Lambda-Funktionen ausführen?

Codezeilen sind eine willkürliche Zählung der Komplexität. Mit Erweiterungsmethoden kann ich Code wie erstellen

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

Alle Nachwuchsprogrammierer sollten gezwungen werden, sich an dieses Prinzip zu halten. Das würde sie dazu zwingen, sich Gedanken über die Struktur zu machen, mit der sie beschäftigt sind, anstatt nur immer mehr Zeilen Code hinzuzufügen.

Ich bin derzeit auf der Suche nach einer Methode von 550 Codezeilen mit vielen if else-Anweisungen, die fortgesetzt werden und in die Return-Anweisungen eingewebt sind. Es ist Mist. Wäre der Programmierer nur gezwungen gewesen, darüber nachzudenken, was er tat ...