Wie Sie wissen, verwenden wir im .NET-Code-Behind-Stil bereits eine Menge Funktionen, um diese _Click-Funktion, _SelectedIndexChanged-Funktion usw. unterzubringen. In unserem Team gibt es einige Entwickler, die mitten in .NET eine Funktion machen Funktion, zum Beispiel:
%Vor%und die oben aufgelistete Funktion wird nur einmal in dieser Funktion verwendet und nirgendwo anders auf der Seite verwendet oder von einem anderen Teil der Lösung aufgerufen.
Sie sagten, dass es den Code übersichtlicher macht, indem Sie sie gruppieren und in eine zusätzliche Unterfunktion extrahieren. Ich kann verstehen, wenn die Unterfunktion im Code immer wieder verwendet wird, aber wenn es nur einmal verwendet wird, dann ist es nicht wirklich eine gute Idee, sie in eine Unterfunktion zu extrahieren, Wenn der Code größer und größer wird, wenn Sie in die Seite schauen und versuchen, die Logik zu verstehen oder zu debuggen, indem Sie Zeile für Zeile abflackern, werden Sie verwirrt, indem Sie von der Hauptfunktion zur Unterfunktion und dann zur Hauptfunktion und springen wieder unterzufunktionieren.
Ich weiß, dass diese Art der Gruppierung nach Methode besser ist, wenn Sie alten ASP- oder ColdFusion-Stil schreiben, aber ich bin mir nicht sicher, ob diese Art von Stil besser für .NET ist oder nicht.
Frage ist: was ist besser, wenn Sie .NET entwickeln, gruppiert ähnliche Logik in eine Sub-Methode besser (obwohl sie nur einmal verwenden), oder einfach zusammen in der Hauptfunktion und fügen Sie // Erklärung hier am Anfang der Logik ist besser?
Ich hoffe, meine Frage ist klar genug.
Danke.
UPDATE: Danke allen für die Antwort und den Input bis jetzt.
Es ist nur so, dass wir alle Logik und Dinge in eine Funktion gebracht haben (wir haben nur 2-3 Entwickler vorher), und plötzlich wachsen wir in das Team mit 7-8 Entwicklern und jeder hat seinen eigenen Stil.
Ich denke, es ist besser, mit dem Erstellen von Richtlinien zu beginnen, weshalb ich das Bedürfnis habe, die Frage zu stellen.
Wenn ich die Frage ignoriere, ob Geschäftslogik im Code enthalten sein sollte oder nicht (das sollte nicht, aber das ist ein Thema für eine andere Frage), würde ich sagen, dass es eine gute Idee ist, Code auf die logischste Ebene umzuwandeln dass es Sinn macht. Wenn man alles in einer Funktion belässt, wird es für jeden viel schwieriger, die gesamte Funktion im Kopf zu behalten. Die Unterteilung in Untermethoden hilft bei einer Reihe von schwer quantifizierbaren Wegen.
Ich denke, Ihr wirkliches Problem hier ist, dass Sie Ihren Code in den Code dahinter setzen, und Sie wollen Ihren Code nicht hinterherhinken ... nun, dann extrahieren Sie diese Geschäftslogik in Business-Klassen.
Ja, Sie müssen Standardkodierungsrichtlinien definieren, wenn nicht als schriftliches Regelwerk, zumindest als Konsens Ihres Teams. Wenn Sie alle zusammenbringen und sie dazu bringen, sich auf einen Stil zu einigen, dann sind Sie auf halbem Weg. Aber erkenne einfach, dass der Stil, den sie wählen, auch nicht das ist, was DU willst.
Persönlich würde ich wahrscheinlich ein Model-View-Controller (oder ähnliches) Muster verwenden, wenn ich Code wie diesen schreibe.
Wie jedoch ein anderes Plakat erwähnt, ist es definitiv eine Frage der persönlichen Vorliebe und des Stils.
Wenn Sie Ihren Code in kleine Arbeitseinheiten aufteilen, wird Ihr Code einfacher zum Komponententest und Debuggen. Je nachdem, was Ihre "DoSomething" -Funktionen tun, können Sie sie sogar in logische Ebenen abstrahieren (oft getrennt als Klassenbibliotheken in .Net) - zum Beispiel: Datenzugriff, Anwendungsdienste, usw., usw.
Solche Routinen in viele kleinere Methoden zu zerlegen hat mindestens zwei Vorteile.
(1) Sie können leichter isoliert als diskrete Fähigkeiten getestet werden
(2) Compileroptimierungen wie Methodeninlining funktionieren nicht mehr, sobald Ihre Methoden ein bestimmtes Maß an Komplexität und / oder Größe erreichen ... Aus diesem Grund allein , Würde ich wählen, viele kleinere Methoden zu haben.
(3) Wenn Sie die Dinge in kleine Chucks zerlegen, können Sie feststellen, dass Sie einige Routinen statisch machen können. Dies bedeutet, dass jede Klasseninstanz zur Laufzeit kleiner ist und Sie daher weniger Zeit in GC verbringen. Dies bedeutet, dass einige Routinen auch leistungsfähiger sind.
Hmm Ich denke nicht, dass es gut ist, Logik und Methoden im GUI-Code beizutreten, es kann nur eine Entschuldigung für ein sehr einfaches Projekt sein. Logik in der GUI zu platzieren ist wirklich nicht die gute Übung, da Sie / Ihre Kollegen diesen Code einige Zeit später beibehalten müssen ...
Ich würde vorschlagen, dass Sie immer die richtige Struktur Ihres Codes behalten, so dass es leicht für Sie und andere ist, Änderungen vorzunehmen, Ihr Projekt und so weiter auf einfache Weise zu erweitern.
Ich schlage vor, Sie erstellen neue Klassen für Logiken + Methoden.
Ihr Projekt
- YourGUICode.cs
- Task1Processor.cs
- Task2Processor.cs
- TaskNProcessor.cs
und in Ihrem GUI-Code können Sie ein Objekt Ihres Task-Prozessors erstellen, Parameter an eine Methode übergeben und zehn Ergebnisse in der GUI anzeigen lassen.
Es geht um Lese- und Wartbarkeit.
Der Compiler oder die Laufzeit von .NET Framework interessiert sich nicht für eine lange Methode oder mehrere kleine Methoden zum Aufruf (Okay, es gibt vielleicht minimale Performance-Differenzen, aber das ist hier nicht der Punkt).
Wenn Sie einen guten Namen dafür finden, dass der Code in einer Untermethode umgestaltet wird, sollten Sie diesen Weg gehen und den Kommentar oder die Erklärung, was der Code tut, weglassen. Denn ein guter Methodenname sollte angeben, was hier abläuft.
Ich bevorzuge es, lange Methoden nur zur besseren Lesbarkeit in kleinere Methoden umzuformen. Auch wenn sie nur einmal benutzt werden.
Ich denke, Funktionen einzuführen ist besser. Wirklich lange Methoden haben ihre eigenen Probleme in der Lesbarkeit und im Debugging. Esp, wenn die Verschachtelung zu tief geht. Wenn Sie beim Durchlaufen von Code sicher sind, dass eine Funktion korrekt ist, können Sie einfach darüber hinweggehen, anstatt durch die perfekten Codezeilen zu gehen
Das ist meistens eine Frage des persönlichen Stils, daher gibt es wahrscheinlich keine richtige Antwort.
Allerdings könnte es eine Reihe von Gründen geben, um in separate Methoden umzuformen. Wie Sie bereits erwähnt haben, ist die Wiederverwendung wahrscheinlich am überzeugendsten. Es gibt auch ein Argument dafür, große Methoden in kleinere Blöcke zu zerlegen - dass eine Methode nur eines tun sollte. Siehe Onkel Bobs Theorie von Clean Code .
Ein weiterer Grund für die Aufschlüsselung einer Methode in kleinere Abschnitte wäre die Unit-Prüfung und / oder die Implementierung von Code-Verträgen.
Jeder hat seinen eigenen Programmierstil, und solange es nicht zu schrecklich ist, sollten Sie es einfach lassen, lernen, damit zu leben. Es gibt nichts Schlimmeres in einem Team als einen Code-Nazi, und wahrscheinlich gibt es Teammitglieder, die deinen Stil nicht mögen.
Während Sie es nicht persönlich mögen, und es bedeutet ein paar mehr Funktionen auf der Seite, wo ist der wirkliche Schaden in der Annäherung genommen? Ich persönlich hätte das nicht so gemacht, aber solange der Code funktioniert und er weder wirklich fugig noch unordentlich ist, ist es nicht das Ende der Welt.
Lesen Sie diese Richtlinien für den Umgang mit Klassenmitgliedern und wenn Sie haben eine Zeit, werfen Sie einen Blick auf dieses Buch:
Programmieren von .NET-Komponenten Von Juval Lowy Verlag: O'Reilly. Es gibt einen ganzen Abschnitt, in dem über C # Coding Standard mit guten Beispielen gesprochen wird.
Mit dieser Art der Codierung ist nichts "falsch", wenn der Code funktioniert, einfach zu warten und zu testen ist. Separate Methoden erleichtern das Testen und die Problemisolierung.
Es gibt eine größere Frage zum Gesamtdesign und die anderen Antworten, die Modell-View-Controller usw. erwähnen, sind Ihrer Zeit wert.
Danke allen für die Antwort und die Eingabe bis jetzt.
Es ist nur so, dass wir alle Logik und Dinge in eine Funktion gebracht haben (wir haben nur 2-3 Entwickler vorher), und plötzlich wachsen wir in das Team mit 7-8 Entwicklern und jeder hat seinen eigenen Stil.
Ich denke, es ist besser, mit dem Erstellen von Richtlinien zu beginnen, weshalb ich das Bedürfnis habe, die Frage zu stellen.
Tags und Links .net c# coding-style