Entwicklerteams haben normalerweise einige Klassenbenennungskonventionen basierend auf Klassenfunktionen und Rollen, die sie in Mustern spielt. Zum Beispiel verwenden wir die folgenden Postfixes :
usw.
Wie lauten die Namenskonventionen für Postfixes / Präfixe, die Ihr Team verwendet?
Es gibt drei Präfixe, die wir verwenden: I , T und _ . Die erste wird für Schnittstellen, die zweite für generische Typen und die dritte für Property Backer verwendet. Ich rate dringend von anderen Präfixen ab. Dies entspricht übrigens den Empfehlungen von Microsoft. BEARBEITEN : Ich meine hier, dass Microsoft empfiehlt, keine anderen Präfixe als I und T zu verwenden. Weitere Informationen finden Sie unter Richtlinien für Namen - Namen von Klassen, Strukturen und Schnittstellen . Ich verletze bereits, indem ich _ verwende, aber ich habe das Bedürfnis, zwischen privaten Feldern und Property-Backern zu unterscheiden, und ich mag die Tatsache, dass _ nicht alphanumerisch ist. / BEARBEITEN
Die Liste der Postfixes ist nahezu endlos. Sie basieren häufig auf dem Namen der Basisklasse / Schnittstelle, z. B. IDispatcher - & gt; EmailDispatcher .
Persönlich mag ich Postfixes wie Info nicht sehr, weil sie zu allgemein sind, da die meisten Klassen sowieso irgendeine Art von Information darstellen. Schließlich möchte ich Service als Postfix anstelle von Manager verwenden.
BEARBEITEN
Ich benutze den Provider Postfix auch sehr oft, wie in der bekannten ApplicationRoleProvider BCL Klasse.
Wir verwenden ein 'I' Präfix für Schnittstellen und das ist es. Im Allgemeinen versuchen wir, die Sprache (wir verwenden mehrere) für die Benennung von Konventionen zu verwenden, um zu vermeiden, Konventionen in unserem Code für Orte zu mischen, an denen wir die bestehenden Konventionen erfüllen müssen. Wir sprechen sozusagen nicht gegen die Sprachstandards, da wir Konventionen mischen müssten.
Nachdem ich in den letzten zehn Jahren mit verschiedenen Projekten und Kodierungsstandards gearbeitet habe, bin ich zu der Überzeugung gelangt, dass je exotischer die Standards werden und je mehr sie in subjektive Bereiche eindringen, desto wahrscheinlicher ist es, dass sie die Leute komplett abschalten behindern die Produktivität des Teams.
Es gibt gute Praktiken, die helfen, Code zum Beispiel leichter zu debuggen (z. B. nicht mehrere Anweisungen in einer Zeile zu stopfen) und dazu beizutragen, effizienteren, robusteren Code zu erzeugen (Variablen definieren, wenn sie sinnvoll initialisiert werden können) mit begrenztem Umfang), aber diejenigen, die keine sehr unvoreingenommenen, objektiven Argumente für sie haben, verlangen normalerweise, dass Entwickler die persönlichen Vorlieben von jemandem abonnieren.
Insbesondere mit den Namenskonventionen sind einige Praktiken geradezu schädlich und kontraproduktiv. Die ungarische Notation setzt z.B. einen vorherrschenden Fokus auf Typen, wenn moderne Entwickler im Allgemeinen mehr auf die Schnittstelle (en), die ein Typ bereitstellt, und Polymorphismus als auf die spezifischen Typen selbst konzentrieren. Ich mag auch die "Manager" -Konvention nicht besonders, da die meisten höheren Klassen, die sich der Komposition bedienen, oft als in diese Kategorie eingeordnet betrachtet werden, und dann wird das Suffix sehr überflüssig und viel zu oft verwendet.
> FXCop erkennt die Präfixe s_ und m_ und wird sich beschweren, wenn Sie sie mischen. Ich mag sie besser als das generische _ Präfix, das C # Entwickler bevorzugen.
I wird immer für Schnittstellen und T für generische Parameter verwendet. Niemand bestreitet das.
Alles andere wird durch Suffixe wie Collection gehandhabt. Ich werde sie nicht auflisten, weil sie entweder offensichtlich sind oder spezifisch für die Bibliotheken meines Unternehmens sind.
Ich habe gemischte Gedanken über Kontrollen. Manchmal benutze ich die richtigen Pascal-Namen, andere Male benutze ich die alten VB-Stil-Präfixe wie txt, cmd, lbl, usw. Es gibt Mertis und Fehler zu beiden.
Für Klassennamen bevorzuge ich Suffixe als Präfixe; z.B. für verschiedene Arten von Block-Klasse habe ich BlockBase, BlockText, BlockCollection, BlockSequence, BlockTable, BlockDocument usw. Ich bevorzuge Suffixe, weil es hilft, sie alphabetisch zu gruppieren.
Um ein anderes Beispiel zu nennen: Wenn ich mehrere Klassen hätte, die IDispatcher implementieren, könnte ich DispatchEmail anstelle von EMailDispatcher bevorzugen.
Andererseits verwende ich alternativ interne Namespaces (d. h. Ordner in einem Projekt / Assembly), um dies zu tun.
Unser Team setzt alle Klassen mit "C" voran, alle Schnittstellen mit I und alle Strukturen mit T. Das ist schrecklich - zumindest beginnen die Klassen mit "C". Weil die Quelldateien den gleichen Namen wie die Klasse haben. Dann, wenn die Quelldateien in alphabetischer Reihenfolge aufgeführt sind, ist es schwer zu finden, was Sie wollen! Da das Projekt mehrere Jahre alt ist, ist das Umbenennen aller Klassen und Quelldateien keine Option, daher bleibt die Konvention erhalten.
Sie haben
vergessenModel für MVC-Modelle View für MVC-Ansichten Wir verwenden auch Manager , wahrscheinlich zu oft, für Klassen, die unter einer anderen Klasse, z.B. UserManager.
Tags und Links class .net naming-conventions