Eine Klasse pro Dateiregel in .NET? [geschlossen]

Ich folge dieser Regel, aber einige meiner Kollegen sind damit nicht einverstanden und argumentieren, dass eine kleinere Klasse mit anderen Klassen in derselben Datei belassen werden kann.

Ein weiteres Argument, das ich ständig höre, ist: "Auch Microsoft tut dies nicht. Warum sollten wir das tun?"

Was ist der allgemeine Konsens darüber? Gibt es Fälle, in denen dies vermieden werden sollte?

Eine Klasse pro Datei gibt Ihnen auch eine bessere Vorstellung davon, was sich bei jedem Einchecken ändert, ohne die Unterschiede in der Datei zu berücksichtigen.

Ich hasse es, wenn Leute absolut denken und sagen, man sollte dies oder das niemals mit so etwas Subjektivem und Pingeligem tun, als müssten wir uns alle einer dummen Vorstellung von richtig und falsch anpassen. Fazit: Mehr als eine Klasse pro Datei ist völlig in Ordnung, wenn es Sinn macht. Mit Sinn meine ich Dinge wie:

1. Erleichtert die Verdauung und Pflege des Codes
2. Macht die Lösung weniger ärgerlich (durch unzählige unnötige Dateien scrollen) und weniger langsam
3. Das Entwicklerteam ist damit als lokale Codierungspraxis einverstanden

Ein wirklich gutes Beispiel dafür, warum ich mehrere Klassen pro Datei haben möchte:

Angenommen, ich habe ein paar Dutzend benutzerdefinierte Ausnahmeklassen, jede ist ein 4-Liner, ich könnte eine separate Datei für jede haben oder ich könnte die Ausnahmen gruppieren und eine Datei pro Gruppe haben. Für mich scheint es der rationalste / pragmatischste Ansatz zu sein, sie zu gruppieren und nur ein paar Dateien zu haben, da dies in Bezug auf Zeit und Codierung effizienter ist (ich muss nicht mit der rechten Maustaste klicken -> Klasse hinzufügen, umbenennen, 50 Mal). Dadurch bleibt die Lösung übersichtlicher und bietet eine bessere Leistung.

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

Manchmal gruppiere ich mehr als eine Klasse in einer Datei, wenn sie eng miteinander verbunden sind und mindestens eine davon sehr klein ist.

Allgemeine "Best Practice" besteht darin, eine Datei pro Klasse zu haben.

Abgesehen von hypothetischen Argumenten und der Konzentration auf Windows .NET mit Visual Studio IDE und wachsenden Softwareprojekten ist es in diesem Zusammenhang nur sinnvoll, eine Klasse pro Datei zu haben.

Im Allgemeinen ist als visuelle Referenz nichts besser als eine Klasse pro Datei. Ja wirklich.

Ich weiß nicht, ob Microsoft dasselbe tut oder nicht, aber sie haben das partialSchlüsselwort erstellt , um eine Klasse auf mehrere Dateien aufzuteilen (dies ist noch schwerwiegender). Es wird häufig verwendet, um den automatisch generierten Designercode von Ihrem benutzerdefinierten Code in derselben Klasse zu trennen (manchmal wird es jedoch verwendet, damit verschiedene Entwickler gleichzeitig über verschiedene Dateien an der Klasse arbeiten können). Microsoft sieht also die Vorteile mehrerer Dateien und jeder hat mit .NET sicher mehrere Gedanken zur Dateiorganisation.

Für verschachtelte Klassen haben Sie keine andere Wahl, als eine Datei oder zumindest die ersten Teile der Klassen in ihnen zu verwenden. In diesem Fall ist eine Datei erforderlich und in Ordnung:

class BicycleWheel {
    class WheelSpoke {
    }
}

Warum sollten Sie sonst mehrere Klassen in einer Datei behalten? Das Argument "weil sie klein sind" oder miteinander verbunden halten nicht viel Wasser, weil Ihre Klassen schließlich mit anderen Klassen verbunden werden. Letztendlich können Sie die Organisation von Objekten in der Datei nicht einfach anhand ihrer Verwendung ableiten, insbesondere wenn die Software weiter wächst.

Wenn Sie Ordner für Namespaces verwenden , kommt es außerdem nie zu einem Konflikt zwischen Klassendateinamen. Es ist auch praktisch , eine Klasse anhand des Dateinamens im Dateisystem zu suchen, wenn Sie sich nicht in einer Entwicklungsumgebung wie Visual Studio befinden (z. B. wenn Sie eine Klasse schnell mit Notepad oder etwas Schnellem / Leichtem bearbeiten möchten ).

So viele gute Gründe ...

In den allermeisten Fällen folge ich der Regel einer Klasse pro Datei. Die einzige Ausnahme, die ich regelmäßig mache, ist die Definition einer Aufzählung, die eng an eine bestimmte Klasse gekoppelt ist. In diesem einen Fall werde ich häufig die Definition der Aufzählung in die Datei dieser Klasse aufnehmen.

Ich glaube auch, dass es einen Typ in einer einzelnen Datei geben sollte.

Es gibt eine Ausnahme von dieser Regel, die erwähnt werden muss: Zwei Klassen, die sich nur durch ein generisches Argument unterscheiden, wie z.

RelayCommand     

und

RelayCommand<T>

Wirklich, das läuft auf persönliche Vorlieben hinaus. Jeder wird "eine Klasse pro Datei" sagen, aber wir alle haben unsere Gründe, dies unter bestimmten Umständen zu vermeiden. Früher hatte ich ein großes Projekt mit ungefähr 300 verschiedenen Aufzählungen. Auf keinen Fall werde ich 300 separate Dateien haben, eine für jede Klasse, wenn einige der Aufzählungen nur Tri-State waren.

Gibt es einen Grund, warum Sie Find für die gesamte Lösung nicht verwenden, auch wenn Personen bestimmte Klassen nicht finden können, wenn sie nicht alle in Dateien enthalten sind, die nach dem benannt sind, was sie sind? Die Verwendung von Suchen spart mir wertvolle Zeit beim Scrollen durch den Projektmappen-Explorer.

Egal wie leicht der Inhalt ist, ich denke, eine Klasse / Schnittstelle / usw. pro Datei ist wichtig.

Wenn ich in Visual Studio an einer großen Lösung arbeite, möchte ich die Dateien sehen können und nicht nach innen schauen müssen, um sie zu sehen. Selbst mit Navigationswerkzeugen wie ReSharper möchte ich eine 1: 1-Zuordnung.

Wenn Sie viele Quelldateien mit wenig oder keinem Inhalt finden (möglicherweise eine Klasse erweitern, aber nichts hinzufügen), sollten Sie Ihr Design möglicherweise überdenken.

Ich finde es sehr nützlich, eine Klasse mit ihrer Standard-Factory-Klasse in derselben Datei zu gruppieren.

Normalerweise hätte ich eine Klasse pro Datei, aber normalerweise müssten Sie nach eigenem Ermessen prüfen, ob die Datei verwandte Klassen enthalten könnte, z. B. die Gruppierung Ihrer Ausnahmen, die von Ihnen und anderen Entwicklern wiederverwendet werden können. In diesem Fall benötigt der Benutzer nur eine Datei und nicht mehrere Dateien.

Der Punkt ist also: Diskretion sollte angewendet werden !!!

Bei größeren Lösungen halte ich es für sehr wertvoll, eine Klasse pro Datei zu haben und dass die Datei den gleichen Namen wie die Klasse hat. Dies erleichtert das Auffinden des Codes, in dem Sie arbeiten müssen, erheblich.

Das StyleCop-Tool für C # verfügt über Standardregeln, die nicht mehr als eine Klasse der obersten Ebene in einem Namespace erfordern (plus eine beliebige Anzahl von Schnittstellen, Delegaten und Aufzählungen in diesem Namespace).

In Fällen von zwei oder mehr Klassen, in denen die zweite und die nachfolgenden Klassen immer nur von der ersten verwendet werden, können und sollten dies innere Klassen sein, die nur für die konsumierende Klasse sichtbar sind.

Irgendwann eine Klasse pro Datei, aber ...

Wenn mehrere Klassen eng miteinander verbunden sind, ist meiner Meinung nach mehr als eine Klasse in derselben Quelldatei BESSER, als jeder Klasse eine kurze Quelldatei zuzuweisen . Die Quelle ist lesbarer und kompakter (und mit #region kann dieselbe Quelle strukturierter sein als zuvor).

Bedenken Sie auch, dass es manchmal NOTWENDIG ist , dieselbe Klasse auf verschiedene Dateien zu verteilen (unter Verwendung von Partial ), da eine Quelldatei mit mehr als 20000 Zeilen selbst mit dem verfügbaren RAM nicht praktisch ist (dies ist jedoch eine andere Frage).

Gelegentlich werde ich eine kleine Klasse mit einer größeren Klasse belassen, aber nur, wenn sie wie ein Objekt und seine Sammlungsklasse oder Fabrik sehr eng miteinander verbunden sind.

Es gibt jedoch ein Problem damit. Schließlich wächst die kleine Klasse bis zu dem Punkt, an dem sie sich in einer eigenen Datei befinden sollte. Wenn Sie sie in die neue Datei verschieben, verlieren Sie den einfachen Zugriff auf Ihren Revisionsverlauf.

dh.

• am montag ändere ich meine klassen x und y in der datei y.css
• am dienstag trenne ich klasse x in ihre eigene datei x.css, weil sie zu groß geworden ist
• am mittwoch will mein vorteil sehen, was ich am montag in klasse x geändert habe, also schaut er sich die geschichte für x.css an, nur x.css zeigt die geschichte nicht vor dienstagsänderungen.

Ist das wirklich ein Problem? :)
Wirklich kleine Klassen, genau wie Enums, können mit anderen zusammengestellt werden. Es gibt eine Regel zu befolgen: Stellen Sie nur Klassen zusammen, die etwas gemeinsam haben.

Als Exkurs - in einem meiner Projekte habe ich eine Datei mit 150 Klassen. Die Datei enthält 10000 Codezeilen. Aber es wird automatisch generiert, so dass es völlig akzeptabel ist :)

Ein Grund für das Einfügen mehrerer verwandter Klassen in eine Datei besteht darin, dass der arme Bastard, der Ihre API verwendet, keinen halben Tag damit verbringen muss, das Boilerplate für Importdeklarationen einzugeben, und der arme Bastard, der den Code pflegen muss, nicht die Hälfte ausgeben muss ein Tag, der durch das Boilerplate der Importdeklaration blättert. Meine Faustregel lautet, dass mehrere Klassen in dieselbe Datei gehören, wenn Sie fast immer eine große Teilmenge von ihnen gleichzeitig und nicht nur eine gleichzeitig verwenden würden.

Ich mache das, aber nur, wenn die Klassen auf untergeordnete Weise miteinander verbunden sind und die untergeordneten Klassen NUR vom übergeordneten Element verwendet werden.

Normalerweise bleibe ich bei einer Klasse pro Datei. Ich werde jedoch Ausnahmen für Gruppen ähnlicher Konstrukte machen, die projektweit verwendet werden. Beispielsweise:

• Eine EventArgs.cs, die beliebige EventArgsUnterklassen enthält , da diese normalerweise nur 5 bis 10 Codezeilen umfassen, aber normalerweise von mehreren verschiedenen Klassen verwendet werden. Alternativ könnte ich die EventArgsKlassen in dieselbe Datei einfügen wie die Klasse, die die Ereignisse deklariert.
• Eine Delegates.cs, die Delegates enthält, die im gesamten Projekt verwendet werden, da sie normalerweise nur jeweils eine Zeile umfassen. Die Alternative besteht wiederum darin, sie in dieselbe Datei mit der Klasse zu legen, die sie verfügbar macht / verbraucht.
• Eine Enums.cs, die enums enthält, die im gesamten Projekt verwendet werden. (Wenn es eine gibt enum, die nur von einer Klasse verwendet wird, schaffe ich es normalerweise privatein diese Klasse.)

Eine weitere Abstimmung für eine Klasse pro Datei, wobei die Datei den gleichen Namen wie die Klasse hat. Für mich hilft es bei der langfristigen Wartbarkeit. Ich kann leicht im Repository nachsehen, welche Klassen Teil einer Lösung sind, ohne das Projekt oder eine der Dateien öffnen zu müssen.

Ich folge ihm 99% der Zeit. Es ist gut, Standards zu befolgen, aber ich glaube auch, dass Flexibilität ihren Platz hat. Manchmal scheint es nur eine dumme Zeitverschwendung zu sein, Dinge auseinanderzubrechen. In diesen Zeiten komme ich über mich selbst hinweg und schreibe einfach meinen Code.

Die bisherigen Antworten scheinen sich um die Ausnahmen der Leute von der Regel zu drehen. Hier ist meine: Ich halte Klassen und ihre Metadaten-Buddy-Klassen zusammen, wenn ich das DataAnnotations-Paket in .NET3.5 SP1 verwende. Ansonsten befinden sie sich immer in separaten Dateien. Weißt du, die meiste Zeit. Außer wenn sie es nicht sind.

Ich mache das nur selten. Zum Beispiel, wenn es eine Aufzählung oder Struktur gibt, die eng mit der Klasse verwandt ist, aber zu trivial, um allein getrennt zu werden.

Oder eine separate Klasse, die einige Erweiterungsmethoden für diese Hauptklasse enthält.

One case could be:Wenn Ihre Klassen gemeinsam eine bilden module / unit, die einigen Hauptklassen wie helper classesanderen dient , nein .

Schauen Sie sich den Quellcode des ASP.NET MVC 2.0- Projekts an. Es folgt strikt dieser Regel

Ich mag die Idee, kleinere Klassen zu erstellen und sicherzustellen, dass die Klasse nur das tut, was sie tun soll. Wenn Sie mehrere Klassen haben, die zur Lösung eines einzelnen Problems beitragen, kann es nicht schaden, sie in derselben Datei zusammenzufassen.

Ich würde MS-Praktiken nicht folgen, da sie nicht die BESTEN PRAXIS sind!

Ein weiterer Punkt, den noch niemand erwähnt hat, ist, dass Sie bei der Entwicklung mit der Regel "Eine Klasse pro Datei" leicht erkennen können, was diese bestimmte Klasse verwendet.

Beispiel: Sie haben möglicherweise zwei Klassen, in denen eine Klasse Linq verwendet und die andere nicht.

Wenn sich diese Klassen in derselben Datei befinden würden, könnten Sie nicht erkennen, ohne den Code durchzusehen, welche Klasse was verwendet. Wenn es sich um eine Klasse pro Datei handelt, müssen Sie nur oben in der Datei nachsehen, was genau in dieser Klasse verwendet wird. Hilft, wenn Sie jemals auf eine neue Bibliothek usw. migrieren.

Ein weiterer Grund für eine Klasse pro Datei, der in den bisher veröffentlichten Antworten nicht erwähnt wurde, ist, dass eine Klasse pro Datei das Verständnis der Auswirkungen einer PR während einer Codeüberprüfung erleichtert. Es reduziert auch Zusammenführungskonflikte.

Wenn jemand eine PR für Feedback veröffentlicht, kann ich mir die Liste der geänderten Dateien ansehen und sofort feststellen, ob sich etwas mit dem überschneidet, woran ich gerade arbeite. Abhängig von der Überlappung möchte ich mir den Code genauer ansehen oder ihm ein OK geben, da ich ziemlich sicher bin, dass er meine eigenen Änderungen nicht beeinflusst.

Wenn zwei Personen in einer Datei mit mehreren Klassen arbeiten und beide eine Abhängigkeit hinzufügen, besteht eine gute Chance, dass im usingBlock oben ein Zusammenführungskonflikt auftritt . Durch das Aufteilen der Klassen in Dateien werden die Abhängigkeiten getrennt, sodass Sie sehen können, was jede Klasse verwendet, und keine derartigen Konflikte auftreten.

Es gibt Ausnahmen von dieser Regel (Schnittstelle + Implementierung, Aufzählungen, ...), aber es ist ein besserer Ausgangspunkt als das Gegenteil, wodurch Junior-Entwickler normalerweise alle Arten von nicht verwandten Klassen in derselben Datei bündeln können.

Eine Klasse pro Datei ist eine eindeutige Regel, die nicht interpretiert werden kann.

Verwandte Klassen in einer Datei unterliegen persönlichen Vorlieben und Interpretationen (wie Sie aus allen anderen Antworten hier ersehen können, wann die Verwendung in Ordnung ist) und sind daher eine schlechte Regel.

Das Hin und Her war sehr interessant und scheinbar nicht schlüssig, obwohl mein allgemeiner Eindruck ist, dass eine 1: 1-Zuordnung zwischen Klassen und Dateien die Mehrheitsmeinung ist, wenn auch mit einigen Ausnahmen von Person zu Person.

Ich bin gespannt, ob eine Ihrer Antworten davon abhängt, ob Sie: (1) eine Windows Forms-App, eine Web-App, eine Bibliothek oder was auch immer entwickeln; oder (2) Visual Studio verwenden oder nicht. Bei der Verwendung von VS scheint die Regel "Eine Klasse pro Datei" auch eine Klasse pro VS-Projekt zu implizieren, da in anderen Threads die Übereinstimmung zu bestehen scheint, dass VS-Lösungen / -Projekte in der Benennung und Struktur des Verzeichnisses / der Datei gespiegelt werden sollten. Mein Eindruck ist in der Tat, dass der Konsens darin besteht, den Projektnamen = Assemblername = (verschachtelter) Namespace-Name zu haben, die dann alle in der Verzeichnis- / Dateinamen und -struktur gespiegelt werden. Wenn dies die richtigen Richtlinien (oder Regeln) sind, werden all diese scheinbar orthogonalen Organisationsmechanismen dennoch synchron gehalten.

Ja, aus Gründen der Lesbarkeit sollten wir eine Datei pro Klasse haben!. Bin gerade in ein Projekt gesprungen. Ich sehe viele Klassen in einer Datei. es macht es einem neuen Mann einfach so schwer, es zu verstehen. sollten wir nicht an Wartbarkeit denken? Wann entwickeln wir eine Software? Viele Male wird die Entwicklung von anderen Entwicklern fortgesetzt. Wir haben Namespaces, um unsere Sachen zu ordnen, wir brauchen keine Dateien, um das zu tun!.

Ein Codeelement pro Datei, ja.

Alles andere ist ein Fehlverhalten - und ehrlich gesagt ein Zeichen für RAD-Opfer.

Sobald man mit der richtigen Softwareentwicklung beginnt (IoC, Entwurfsmuster, DDD, TDD usw.) und den Spielplatz "Omg lasst uns das erledigen, ich habe keine Ahnung wie, aber ich werde bezahlt" verlässt, wird man das sehen Diese Regel ist wirklich wichtig.