Benennungsregeln und -konventionen für C#-Bezeichner
Ein Bezeichner ist der Name, den Sie einem Namespace, einem Member, einer Variable oder einem Typ (Klasse, Schnittstelle, Struktur, Delegat oder Enumeration) zuweisen.
Benennungsregeln
Gültige Bezeichner müssen diese Regeln einhalten. Der C#-Compiler erzeugt einen Fehler für jeden Bezeichner, der nicht den folgenden Regeln entspricht:
- Bezeichner müssen mit einem Buchstaben oder mit einem Unterstrich (
_
) beginnen. - Bezeichner können Unicode-Buchstaben, Dezimalziffernzeichen, Unicode-Verbindungszeichen, Unicode-Kombinationszeichen oder Unicode-Formatierungszeichen enthalten. Weitere Informationen zu den Kategorien von Unicode finden Sie in der Unicode-Kategoriedatenbank.
Sie können Bezeichner deklarieren, die mit C#-Schlüsselworten übereinstimmen, indem Sie das Präfix @
für den Bezeichner verwenden. @
ist nicht Teil des Bezeichnernamens. Beispielsweise deklariert @if
einen Bezeichner namens if
. Diese ausführlichen Bezeichner dienen in erster Linie der Interoperabilität mit Bezeichnern, die in anderen Sprachen deklariert werden.
Eine vollständige Definition der gültigen Bezeichner finden Sie im Artikel „Bezeichner“ in der C#-Sprachspezifikation.
Wichtig
Die C#-Sprachspezifikation erlaubt nur Buchstaben (Lu, Ll, Lt, Lm, Lo oder Nl), Ziffern (Nd), Verbindungen (PC), Kombinationen (Mn oder Mc) und Formatierungskategorien (Cf). Alles außerhalb, das automatisch durch _
ersetzt wird. Dies kann sich auf bestimmte Unicode-Zeichen auswirken.
Namenskonventionen
Neben den Regeln werden Konventionen für Bezeichnernamen in allen .NET-APIs verwendet. Diese Konventionen bieten Konsistenz für Namen, aber der Compiler erzwingt sie nicht. Sie können in Ihren Projekten verschiedene Konventionen verwenden.
Gemäß der Konventionen verwenden C#-Programme PascalCase
für Typnamen, Namespaces und alle öffentlichen Member. Darüber hinaus verwendet das dotnet/docs
-Team die folgenden Konventionen, die vom Codierungsstil des .NET-Runtimeteams übernommen wurden:
Schnittstellennamen beginnen mit einem großen
I
.Attributtypen enden mit dem Wort
Attribute
.Enumerationstypen enthalten ein Substantiv im Singular für Nicht-Flags und ein Substantiv im Plural für Flags.
Bezeichner dürfen keine zwei aufeinanderfolgenden Unterstriche (
_
) enthalten. Diese Namen sind für Bezeichner reserviert, die der Compiler generiert.Verwenden Sie aussagekräftige und beschreibende Namen für Variablen, Methoden und Klassen.
Bevorzugen Sie Lesbarkeit gegenüber Kürze.
Verwenden Sie PascalCase für Klassen- und Methodennamen.
Verwenden Sie camelCase für Methodenparameter und lokale Variablen.
Verwenden Sie PascalCase für Konstantennamen, sowohl für Felder als auch für lokale Konstanten.
Private Instanzfelder beginnen mit einem Unterstrich (
_
) und der restliche Text wird in camelCase geschrieben.Statische Felder beginnen mit
s_
. Diese Konvention ist nicht das Visual Studio-Standardverhalten oder Teil der Framework-Entwurfsrichtlinien, ist aber in der EDITORCONFIG-Datei konfigurierbar.Vermeiden Sie Abkürzungen oder Akronyme in Namen, mit Ausnahme von allgemein bekannten und akzeptierten Abkürzungen.
Verwenden Sie aussagekräftige und beschreibende Namespaces, die der umgekehrten Domänennamennotation folgen.
Wählen Sie Assemblynamen aus, die den primären Zweck der Assembly widerspiegeln.
Vermeiden Sie die Verwendung von Namen, die nur aus Einzelbuchstaben bestehen (außer für einfache Schleifenzähler). In den Beispielen zur Beschreibung der Syntax von C#-Konstrukten werden außerdem häufig Namen mit Einzelbuchstaben verwendet, die der Konvention entsprechen, die in der C#-Sprachspezifikation verwendet wird. Syntaxbeispiele sind eine Ausnahme der Regel.
- Verwenden Sie
S
für Strukturen undC
für Klassen. - Verwenden Sie
M
für Methoden. - Verwenden Sie
v
für Variablen undp
für Parameter. - Verwenden Sie
r
fürref
-Parameter.
- Verwenden Sie
Tipp
Sie können Namenskonventionen erzwingen, die Groß-/Kleinschreibung, Präfixe, Suffixe und Worttrennzeichen betreffen, indem Sie Benennungsregeln im Codeformat verwenden.
In den folgenden Beispielen gelten die Hinweise für als public
markierte Elemente auch für die Arbeit mit protected
- und protected internal
-Elementen, die alle auch für externe Aufrufer sichtbar sein sollen.
PascalCase
Verwenden Sie die Pascal-Groß-/Kleinschreibung („PascalCasing“), wenn Sie einen class
-, interface
-, struct
- oder delegate
-Typ benennen.
public class DataService
{
}
public record PhysicalAddress(
string Street,
string City,
string StateOrProvince,
string ZipCode);
public struct ValueCoordinate
{
}
public delegate void DelegateType(string message);
Verwenden Sie beim Benennen eines die interface
Pascal-Groß-/Kleinschreibung zusätzlich zum Präfix des Namens mit einem I
. Dieses Präfix gibt den Consumern deutlich an, dass es sich um ein interface
handelt.
public interface IWorkerQueue
{
}
Beim Benennen von public
-Membern von Typen, z. B. Feldern, Eigenschaften und Ereignissen, wird die Pascal-Groß-/Kleinschreibung verwendet. Verwenden Sie die Pascal-Groß-/Kleinschreibung außerdem für alle Methoden und lokalen Funktionen.
public class ExampleEvents
{
// A public field, these should be used sparingly
public bool IsValid;
// An init-only property
public IWorkerQueue WorkerQueue { get; init; }
// An event
public event Action EventProcessing;
// Method
public void StartEventProcessing()
{
// Local function
static int CountQueueItems() => WorkerQueue.Count;
// ...
}
}
Verwenden Sie beim Schreiben von Positionsdatensätzen die Pascal-Groß-/Kleinschreibung für Parameter, da es um die öffentlichen Eigenschaften des Datensatzes geht.
public record PhysicalAddress(
string Street,
string City,
string StateOrProvince,
string ZipCode);
Weitere Informationen zu Positionsdatensätzen finden Sie unter Positionssyntax für die Eigenschaftendefinition.
Camel case
Verwenden Sie die gemischte Groß-/Kleinschreibung (camelCasing), wenn Sie private
- oder internal
-Felder benennen, und stellen Sie ihnen das Präfix _
voran. Verwenden Sie camelCasing beim Benennen lokaler Variablen, einschließlich Instanzen eines Delegattyps.
public class DataService
{
private IWorkerQueue _workerQueue;
}
Tipp
Wenn Sie C#-Code bearbeiten, der diesen Benennungskonventionen in einer IDE entspricht, die die Anweisungsvervollständigung unterstützt, zeigt die Eingabe _
alle objektbezogenen Member an.
Wenn Sie mit static
Feldern arbeiten, die private
oder internal
sind, verwenden Sie das Präfix s_
und für Thread statisch t_
.
public class DataService
{
private static IWorkerQueue s_workerQueue;
[ThreadStatic]
private static TimeSpan t_timeSpan;
}
Verwenden Sie beim Schreiben von Methodenparametern die Camel-Groß-/Kleinschreibung.
public T SomeMethod<T>(int someNumber, bool isValid)
{
}
Weitere Informationen zu C#-Benennungskonventionen finden Sie im Codierungsstil des .NET-Runtime-Teams.
Richtlinien für die Benennung von Typparametern
Die folgenden Richtlinien gelten für Typparameter in generischen Typparametern. Typparameter sind die Platzhalter für Argumente in einem generischen Typ oder einer generischen Methode. Weitere Informationen zu generischen Typparametern finden Sie im C#-Programmierleitfaden.
Verwenden Sie zur Benennung von generischen Typparametern beschreibende Namen, es sei denn, ein Name aus einem einzelnen Buchstaben reicht als Erklärung völlig aus, und ein beschreibender Name würde das Verständnis für den Namen nicht wirklich erhöhen.
public interface ISessionChannel<TSession> { /*...*/ } public delegate TOutput Converter<TInput, TOutput>(TInput from); public class List<T> { /*...*/ }
Ziehen Sie die Verwendung von
T
als Typparametername für Typen in Betracht, die einen einzelnen Buchstaben als Typparameter aufweisen.public int IComparer<T>() { return 0; } public delegate bool Predicate<T>(T item); public struct Nullable<T> where T : struct { /*...*/ }
Verwenden Sie das Präfix „T“ für beschreibende Typparameternamen.
public interface ISessionChannel<TSession> { TSession Session { get; } }
Überlegen Sie, ob Sie Einschränkungen, die für einen Typparameter gelten, im Namen des Parameters angeben möchten. So können Sie einen auf
ISession
eingeschränkten Parameter z. B.TSession
nennen.
Die Codeanalyseregel CA1715 kann verwendet werden, um sicherzustellen, dass Typparameter entsprechend benannt werden.
Weitere Benennungskonventionen
Verwenden Sie Namespacequalifizierungen in kurzen Beispielen, die keine Nutzungs-Anweisungen umfassen. Wenn Sie wissen, dass ein Namespace standardmäßig in ein Projekt importiert wird, müssen Sie den Namen aus diesem Namespace nicht voll qualifizieren. Qualifizierte Namen können nach einem Punkt (.) unterbrochen werden, wenn sie für eine einzelne Zeile zu lang sind, wie im folgenden Beispiel gezeigt.
var currentPerformanceCounterCategory = new System.Diagnostics. PerformanceCounterCategory();
Sie müssen nicht die Namen der Objekte ändern, die mit den Designertools von Visual Studio erstellt wurden, um sie an andere Richtlinien anzupassen.