Codierungsrichtlinie: Methoden sollten nicht mehr als 7 Anweisungen enthalten?

78

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.

Brian
quelle
48
Zählen sie auch caseAussagen in einem Satz switch? Auf jeden Fall ist es nichts anderes als eine idiotische, nutzlose Anforderung. Diejenigen, die es geschrieben haben, wissen nichts über Programmierung.
SK-logic
86
Die einzige Regel, die in der Kodierungsnorm eine "1" sein sollte, sollte die Regel "Du sollst alle Kodierungsrichtlinien mit einem Körnchen Salz einhalten" sein.
Mike Nakis
6
@ SK-logic 1027 ist auch nicht schlecht - es muss Spaß machen, Code zu schreiben, der mit fehlenden Daten umgehen muss, wenn Sie eine leere Zeichenfolge als Nullzeichenfolge behandeln müssen.
quant_dev
25
Beim Lesen dieser Richtlinie würde ich erwarten, dass eine Codebasis voll ist mit: void DoSomething () {DoSomethingFirstSevenLines (); DoSomethingSecondSevenLines (); DoSomethingThirdSevenLines (); usw; }
Schlepper
12
Versuchen Sie, das meiste von .NET Framework zu reflektieren, und sehen Sie, wie viele Methoden weniger als 7 Anweisungen haben ...
David Boike

Antworten:

195

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.

TMN
quelle
25
+1 für "Mikromanagement durch Proxy" Ich vermute, dass jemand etwas über die "7 plus oder minus 2" -Regel gelesen hat ( en.wikipedia.org/wiki/… ) und die kurzfristige Aufbewahrung von Fakten mit der langfristigen Speicherung wie einem Code-Editor verwechselt hat.
flauschige
25
Jeder vernünftig durchdachte Standard verbietet magische Zahlen im Code, oder? Man könnte meinen, der Kodierungsstandard würde auch an diesem Standard festhalten. Die Nummer 7 hat definitiv eine "magische" Qualität.
Adam Crossland
2
Ihre Antwort wäre sinnvoller, wenn der Titel des Dokuments nicht "Codierung Guidlinesfür C # 3.0 und 4.0.
Andy
+1 Meines Erachtens sollten Sie Codierungsstandards nur deshalb befolgen, um niemals dogmatisch einer beliebigen Zahl zu folgen, sondern um sicherzustellen, dass Sie bei der Versionskontrolle keine unnötigen Probleme beim Zusammenführen verursachen (dh Probleme, die bei der Arbeit in einem Team auftreten). In der Regel sind kürzere Dateien und mehr Komponenten weniger problematisch, wenn Sie Codeänderungen zusammenführen.
Spoike
3
Ich habe dieses Dokument heruntergeladen und angefangen, es zu durchsuchen. In 1.6 heißt es: "Das Dokument besagt nicht, dass Projekte diesen Richtlinien entsprechen müssen, und es sagt auch nicht, welche Richtlinien wichtiger sind als andere. Wir ermutigen Projekte jedoch, selbst zu entscheiden, welche Richtlinien wichtig sind und welche Abweichungen ein Projekt bewirken wird Verwenden Sie, wer der Berater ist, wenn Zweifel auftauchen, und welche Art von Layout für den Quellcode verwendet werden muss. " Auch wenn eine 1 "Richtlinien, die Sie niemals überspringen sollten und die für alle Lösungen gelten sollten" bedeutet, können Sie sie ändern.
chrish
83

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.

deadalnix
quelle
1
Gute Antwort. Die letzten beiden Zeilen bringen den Punkt besonders in Fahrt.
Xonatron
6
Ich denke, die wichtige Faustregel ist, zu überprüfen, ob die Untermethoden orthogonal sind. Wenn sie unabhängig sind, in beliebiger Reihenfolge aufgerufen werden können und die Klasseninvariante respektieren, ist es besser, sie getrennt zu halten. Wenn die Methoden eng miteinander verbunden sind, Klasseninvarianten unterbrechen und / oder in einer bestimmten Reihenfolge aufgerufen werden müssen, ist es möglicherweise besser, sie zusammenzuhalten.
Hugomg
4
Code complete steckt voller guter Sachen. Jeder Programmierer sollte jeden Tag ein Stück davon zum Mittagessen essen.
Deadalnix
29

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."

seggy
quelle
7
Die Spaltenbeschränkung "80/100/120" ist so, dass wir den Code lesen können. Die meisten Terminals öffnen bei 80 Spalten, und es ist weniger aufwendig, den Autor zum Umbrechen auf 80 Spalten zu bringen, als dafür zu sorgen, dass jeder Leser die Größe seines Terminals jedes Mal ändert, wenn er den Code lesen möchte. Im Gegensatz zu den anderen Grenzwerten wirkt sich das N-Spalten-Limit nicht auf die Semantik des Codes aus, sondern ist eine rein stilistische Regel. In derselben Kategorie wie "Verwenden von Tabulatoren mit 4 Leerzeichen" oder "Platzieren von öffnenden Klammern für Funktionen in einer eigenen Zeile".
Dietrich Epp
4
Zugegeben, es ist mehr ein ästhetischer als ein semantischer Aspekt. Hier gilt jedoch mein letzter Satz. Es ist nicht ungewöhnlich, Java-Anweisungen zu finden, die die 80-Spalten-Regel überschreiten, ohne einen "netten" Platz zum Teilen der Zeile. Dies beeinträchtigt die Lesbarkeit und das Verständnis des Codes. Es könnte auch auf Verstöße gegen das Gesetz von Demeter
hinweisen
7
Im 21. Jahrhundert hat meine IDE diese Funktion "dynamischer Zeilenumbruch".
György Andrasek
9
@ GyörgyAndrasek: Aber nicht jeder verwendet Ihre IDE immer: Wir betrachten Code in GitHub, in Terminals mit less, in vimund emacs; und automatisches Wickeln scheint bestenfalls willkürlich. Codierungsstandards sind nicht zu Ihrem Vorteil, sondern zum Vorteil von Menschen, die in Teams arbeiten.
Dietrich Epp
2
@DietrichEpp Persönlich habe ich Schwierigkeiten, Code zu lesen, der immer in Spalte 80 eingeschlossen ist. Vor kurzem musste ich an einem Java-Projekt arbeiten, in dem der Standard-Eclipse-Formatierer verwendet wurde. Und innerhalb einer Methode war es sehr schwierig, Linien zu verfolgen, die über zwei oder sogar drei Zeilen gingen (ich beschuldige aber auch die anderen Formatierungseinstellungen dafür). Fazit ist, dass ich denke, dass die 80 ein bisschen veraltet ist. Ich persönlich benutze ein Limit von 120, habe meine Editoren eingestellt, um dies zu erzwingen, habe eine Konsole, die 120 Spalten breit ist und Github zeigt tatsächlich 125 Spalten an. Und ich denke, dass es so viel lesbarer ist.
Stöbern Sie
18

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.

Joshua Smith
quelle
1
+1 für die Lesbarkeit. Es sollte nicht einmal wichtig sein, ob eine Methode 20, 30 oder sogar 50 Zeilen lang ist. Wenn DRY und SRP Ihre Ziele sind, spielt es keine Rolle, ob die Methoden etwas zu lang wirken ... obwohl Sie am häufigsten feststellen, dass Ihre Methoden umso kürzer sind, je lesbarer Sie versuchen, Ihren Code zu gestalten wird natürlich werden.
S.Robins,
11

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.

Nathan Long
quelle
Das macht es dann zu einer ziemlich expliziten Annäherung. Es ist unter "Richtlinien, die Sie niemals überspringen sollten und die auf alle Situationen anwendbar sein sollten" markiert.
Brian
1
@brian - vielleicht haben die Richtlinienschreiber das Wort "grob" versehentlich weggelassen, oder vielleicht waren sie verrückte Diktatortypen. Mein Punkt ist, dass das OP dies als eine Baseball-Nummer nehmen sollte. Jede Regel, die der Compiler oder Interpreter nicht durchsetzt, ist nur ein Vorschlag.
Nathan Long
"Jede Regel, die der Compiler oder Interpreter nicht durchsetzt, ist nur ein Vorschlag." Nicht unbedingt wahr. Ich habe mich nicht mit seinen benutzerdefinierten Resharper- oder FXCOP-Regeln befasst und ob sie diese bestimmte Regel tatsächlich durchsetzen, aber es gibt Unternehmen, die Sie dazu zwingen, alle Stilrichtlinien einzuhalten. Ich habe Leute getroffen, deren Unternehmen sie dazu zwingt, Code zu schreiben, der die strengen Codierungsrichtlinien von Microsoft erfüllt.
Brian
Ich bin damit einverstanden, dass es sich um eine ungefähre Angabe handelt und dass sie von einem Körnchen Salz genommen werden sollte. Wenn ein Abschnitt des Codestandards eine beliebige Zahl enthält, führt dies unweigerlich zu Verwirrung. Meistens werden Standards aus dem Zusammenhang gerissen und "Menschen" werden dieser willkürlichen Annäherung als Dogma folgen.
Spoike
10

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.

Jim McKeeth
quelle
1
+1: Beliebige Limits sind nur willkürlich sinnvoll. Eine Methode sollte eine einzige zusammenhängende Operation auf einer einzigen Abstraktionsebene enthalten. Das Zerbrechen einer solchen atomaren Einheit macht den Code komplexer und erschwert das Verstehen des Codes.
Allon Guralnek
DRY ist überbewertet. Sehr oft bedeutet es, zwei Aspekte von etwas eng miteinander zu verbinden, die nicht so eng miteinander verbunden sein sollten.
Brad Thomas
4

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

Jaydee
quelle
8
Sie können den Boilerplate-Code nicht in eine eigene Methode abstrahieren?
Erjiang
Ich bemerkte nach dem Posten, dass dies C # ist, nicht Java, aber ich denke über so etwas nach. stackoverflow.com/questions/321418/…
Jaydee
@ Erjang: Sie können. In Java ist das sehr hässlich, da Sie jede Abfrage in eine anonyme Klasse einbinden müssen, aber es sich trotzdem lohnt, dies zu tun. Nicht so hässlich in C #, und auf jeden Fall lohnt es sich, es zu tun.
Kevin Cline
Persönlich finde ich ein paar zusätzliche Zeilen geraden Zeilencodes besser lesbar. Aber vielleicht bin das nur ich.
Jaydee
@Jaydee Die verknüpfte Frage zeigt die übliche, aber seltsame Vorgehensweise: Ausnahme umbrechen und Protokollierung. Auf der nächsten Ebene können Sie dasselbe tun ... auf diese Weise wird eine einzelne Ausnahme mehrmals im Protokoll angezeigt. Es wäre besser, die Methode throw zu deklarieren, und Sie haben 3 Zeilen gespeichert. Schreiben Sie eine Hilfsmethode, die beide psund schließt, rsund speichern Sie eine andere. Oder schreiben Sie eine Methode, List<Row> readDb(String sql, Object... args)die die ganze Arbeit erledigt (funktioniert nur für Ergebnismengen, die in den Speicher passen, aber das Abrufen zu vieler Daten impliziert normalerweise, dass die Arbeit in der Datenbank sowieso erledigt werden sollte).
Maaartinus
4

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.

Asveikau
quelle
4

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.

Bill K
quelle
4

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.

Dennis Doomen
quelle
3
Gut, dass Sie mitmachen, und ich denke, Sie machen ein vernünftiges Argument. Das heißt, ich stimme nicht mit Ihrer Begründung überein, dass "sie immer Entwickler sind, die ihre Richtlinien explizit haben wollen": Sie können nicht immer auf Idioten eingehen, und Sie sollten es nicht versuchen. Richtlinien explizit zu formulieren ist gut, solange dies nicht falsch macht: Jetzt ist es keine Richtlinie mehr, es ist eine willkürliche Regel. Wie Sie gesehen haben, ist die Einführung willkürlicher Zahlen eine absolut sichere Methode, um abgeschossen und gerechtfertigt zu werden.
Konrad Rudolph
3

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.

Dominic Cronin
quelle
2

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.

Falcon165o
quelle
6
"Ich bin mit der obigen Aussage einverstanden" Vermeiden Sie diese Art von Sätzen in Stack-Exchange-Sites. Denken Sie daran, dass die Reihenfolge, in der die Antworten veröffentlicht werden, nicht unbedingt der Reihenfolge entspricht, in der sie angezeigt werden.
Luiscubal
Ich weiß, ich habe nicht darüber nachgedacht, bis es zu spät war. Aber ich werde dir trotzdem +1 geben, weil du auf meinen Hirnfurz hingewiesen hast.
Falcon165o
2

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.

James Anderson
quelle
Ich denke , es ist ziemlich sicher zu sagen , dass try/ catch/ finallysind keine Aussagen in C #. Siehe Ecma-334 § 12.3.3.15 und die umliegenden Abschnitte. (abgekürzt) " eine try-catch-finally-Anweisung des Formulars : try -block catch (...) catch-block-n endlich finally-block "
ein CVn
Nun, wie ich bereits sagte, es ist eine Entscheidung, die Sie immer und immer wieder treffen müssen. Ihr spezielles Beispiel könnte jedoch ein Beispiel dafür sein, dass objektorientiertes Design nicht korrekt ausgeführt wird. Möglicherweise möchten Sie Ihren Bildschirm in mehrere Steuerelemente unterteilen, die die Validierung selbst durchführen.
Dennis Doomen
@ Tennis - wahr, mache schon zu lange HTML-Formulare!
James Anderson
@James Und genau dafür ist diese Richtlinie gedacht. Versuchen Sie, sich alternative, möglicherweise bessere Lösungen auszudenken.
Dennis Doomen
2

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.

authentictech
quelle
0

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.. }

Dinesh Arora
quelle
1
Siehe auch meine Antwort auf James Andersons Frage. In Ihrem speziellen Fall frage ich mich, ob diese Validierungsmethode nicht mehrere Prinzipien und Richtlinien gleichzeitig verletzt.
Dennis Doomen
0

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());   });
Justin
quelle
Wieder ein großartiges Beispiel dafür, wie man mit einer einzigen Methode zu viel macht. In fast allen Gegenargumenten verstoßen Menschen gegen das Prinzip der Einzelverantwortung (im Kontext einer Methode).
Dennis Doomen
-1

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 ...

dawidg
quelle