Allgemeine Benennungskonventionen
Hinweis
Diese Inhalte wurden mit Genehmigung von Pearson Education, Inc. aus Framework Design Guidelines nachgedruckt: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Diese Ausgabe wurde 2008 veröffentlicht, und das Buch wurde seitdem in der dritten Ausgabe vollständig überarbeitet. Einige der Informationen auf dieser Seite sind möglicherweise veraltet.
In diesem Abschnitt werden allgemeine Benennungskonventionen beschrieben, die sich auf Wortwahl, Richtlinien zur Verwendung von Abkürzungen und Akronymen und Empfehlungen zum Vermeiden der Verwendung sprachspezifischer Namen beziehen.
Wortwahl
✔️ WÄHLEN Sie leicht lesbare Bezeichnernamen aus.
Beispielsweise ist eine Eigenschaft namens HorizontalAlignment im Englischen besser lesbar als AlignmentHorizontal.
✔️ BEVORZUGEN Sie Lesbarkeit gegenüber Kürze.
Der Eigenschaftsname CanScrollHorizontally ist besser als ScrollableX (ein unklarer Verweis auf die X-Achse).
❌ Verwenden Sie KEINE Unterstriche, Bindestriche oder andere nicht alphanumerische Zeichen.
❌ Verwenden Sie KEINE ungarische Notation.
❌ VERMEIDEN Sie die Verwendung von Bezeichnern, die mit Schlüsselwörtern häufig verwendeter Programmiersprachen in Konflikt stehen.
Gemäß Regel 4 der Common Language Specification (CLS) müssen alle konformen Sprachen einen Mechanismus bereitstellen, der den Zugriff auf benannte Elemente ermöglicht, die ein Schlüsselwort dieser Sprache als Bezeichner verwenden. C# verwendet in diesem Fall beispielsweise das @-Zeichen als Escapemechanismus. Es ist jedoch trotzdem eine gute Idee, gängige Schlüsselwörter zu vermeiden, da es viel schwieriger ist, eine Methode mit der Escapesequenz als ohne diese zu verwenden.
Verwenden von Abkürzungen und Akronymen
❌ Verwenden Sie KEINE Abkürzungen oder Zusammenziehungen als Teil von Bezeichnernamen.
Verwenden Sie beispielsweise GetWindow statt GetWin.
❌ Verwenden Sie KEINE Akronyme, die nicht allgemein akzeptiert sind, und selbst wenn dies der Fall ist, nur wenn dies wirklich notwendig ist.
Vermeiden sprachspezifischer Namen
✔️ VERWENDEN Sie semantisch interessante Namen anstelle von sprachspezifischen Schlüsselwörtern für Typnamen.
Beispielsweise ist GetLength ein besserer Name als GetInt.
✔️ VERWENDEN Sie in den seltenen Fällen, wenn ein Bezeichner über seinen Typ hinaus keine semantische Bedeutung hat, einen generischen CLR-Typnamen anstelle eines sprachspezifischen Namens.
Eine Methode, die in Int64 konvertiert wird, sollte z. B. den Namen ToInt64 tragen, nicht ToLong (da Int64 ein CLR-Name für den C#-spezifischen Alias long ist). Die folgende Tabelle enthält mehrere Basisdatentypen, die die CLR-Typnamen verwenden (sowie die entsprechenden Typnamen für C#, Visual Basic und C++).
| C# | Visual Basic | C++ | CLR |
|---|---|---|---|
| sbyte | SByte | char | SByte |
| Byte | Byte | unsigned char | Byte |
| short | Short | short | Int16 |
| ushort | UInt16 | unsigned short | UInt16 |
| int | Integer | int | Int32 |
| uint | UInt32 | unsigned int | UInt32 |
| long | Long | __int64 | Int64 |
| ulong | UInt64 | __int64 ohne Vorzeichen | UInt64 |
| float | Single | float | Single |
| double | Double | double | Double |
| bool | Boolean | bool | Boolescher Wert |
| char | Char | wchar_t | Char |
| string | String | String | String |
| object | Object | Object | Object |
✔️ VERWENDEN Sie in den seltenen Fällen, in denen ein Bezeichner keine semantische Bedeutung hat und der Typ des Parameters nicht wichtig ist, einen allgemeinen Namen wie value oder item, anstatt den Typnamen zu wiederholen.
Benennen neuer Versionen vorhandener APIs
✔️ VERWENDEN Sie beim Erstellen neuer Versionen einer vorhandenen API einen Namen, der dem der alten API ähnelt.
Dadurch wird die Beziehung zwischen den APIs hervorgehoben.
✔️ BEVORZUGEN Sie das Hinzufügen eines Suffixes anstelle eines Präfixes, um eine neue Version einer vorhandenen API anzuzeigen.
Dies hilft beim Durchsuchen der Dokumentation oder bei Verwendung von IntelliSense bei der Ermittlung. Die alte Version der API wird in der Nähe der neuen APIs angeordnet, da die meisten Browser und IntelliSense Bezeichner in alphabetischer Reihenfolge anzeigen.
✔️ ERWÄGEN Sie die Verwendung eines vollständig neuen, aber aussagekräftigen Bezeichners, anstatt ein Suffix oder Präfix hinzuzufügen.
✔️ VERWENDEN Sie ein numerisches Suffix, um eine neue Version einer vorhandenen API anzuzeigen, insbesondere, wenn der vorhandene Name der API der einzige sinnvolle Name ist (d. h. wenn es sich um einen Branchenstandard handelt) und wenn das Hinzufügen eines sinnvollen Suffixes (oder das Ändern des Namens) keine geeignete Option ist.
❌ Verwenden Sie NICHT das Suffix „Ex“ (oder ähnlich) für einen Bezeichner, um ihn von einer früheren Version derselben API zu unterscheiden.
✔️ VERWENDEN Sie das Suffix „64“, wenn Sie Versionen von APIs einführen, die eine 64-Bit-Ganzzahl („long integer“) anstelle einer 32-Bit-Ganzzahl verarbeiten. Sie müssen diesen Ansatz nur verwenden, wenn die vorhandene 32-Bit-API vorhanden ist. Verwenden Sie ihn nicht für ganz neue APIs, von denen es nur eine 64-Bit-Version gibt.
Teile ©2005, 2009 Microsoft Corporation. Alle Rechte vorbehalten.
Nachdruck mit Genehmigung von Pearson Education, Inc aus Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition von Krzysztof Cwalina und Brad Abrams, veröffentlicht am 22. Oktober 2008 durch Addison-Wesley Professional als Teil der Microsoft Windows Development Series.