Sie können keine Variablen mit Leerzeichen im Namen definieren, da C# das Leerzeichen zur Trennung von Bezeichnern verwendet. Schemata für die Groß-/Kleinschreibung können das Problem der Verwendung zusammengesetzter Namen oder Ausdrücke im Quellcode verringern.

Im Folgenden sind einige bekannte Namens- und Bezeichnungskonventionen aufgeführt:

Kamel-Koffer

Auch bekannt als Kamelhauben, ist die Praxis, Sätze ohne Leerzeichen oder Interpunktion zu schreiben und Wörter mit einem einzigen Großbuchstaben zu trennen. Der allererste Buchstabe wird klein geschrieben.

Lokale Variablen und Methodenparameter werden in der Regel in Großbuchstaben geschrieben. Zum Beispiel:

examplePlayerController
maxHealthPoints
endOfFile

Fall Pascal

Die Pascalsche Großschreibung ist eine Variante der Kamelschreibweise, bei der der Anfangsbuchstabe groß geschrieben wird. Verwenden Sie dies für Klassen- und Methodennamen in der Unity-Entwicklung. Öffentliche Felder können auch pascal case sein. Zum Beispiel:

BeispielSpielerController
MaxHealthPoints
EndOfFile

Schlangenfall

In diesem Fall werden die Leerzeichen zwischen den Wörtern durch einen Unterstrich ersetzt. Zum Beispiel:

example_player_controller
max_health_points
end_of_file

Dönerkiste

Hier werden die Leerzeichen zwischen den Wörtern durch Bindestriche ersetzt. Die Wörter erscheinen dann auf einer Art "Spieß" aus Bindestrichzeichen. Zum Beispiel:

example-player-controller
Max-health-points
Ende der Datei

Das Problem mit der Kebab-Großschreibung ist, dass viele Programmiersprachen den Bindestrich als Minuszeichen verwenden. Außerdem interpretieren einige Sprachen durch Bindestriche getrennte Zahlen als Kalenderdaten.

Ungarische Notation

Der Name einer Variablen oder Funktion gibt oft ihren Zweck oder Typ an. Zum Beispiel:

int iZähler
string strPlayerName

Die ungarische Notation ist eine ältere Konvention und wird in der Unity-Entwicklung nicht häufig verwendet.

Beachten Sie diese Regeln für Ihre Variablen und Felder:

• Verwenden Sie Substantive für Variablennamen: Variablennamen sollten klar und beschreibend sein, da sie eine bestimmte Sache oder einen bestimmten Zustand darstellen. Verwenden Sie bei der Benennung ein Substantiv, außer wenn die Variable vom Typ bool ist (siehe unten).
• Boolesche Wörter mit einem Verb vorangestellt: Diese Variablen zeigen einen wahren oder falschen Wert an. Oft sind sie die Antwort auf eine Frage, wie zum Beispiel: Ist der Spieler auf der Flucht? Ist das Spiel vorbei?
• Stellen Sie ihnen ein Verb voran, um ihre Bedeutung zu verdeutlichen. Oft ist dies mit einer Beschreibung oder einem Zustand gekoppelt, z. B. isDead, isWalking, hasDamageMultiplier usw.
• Verwenden Sie aussagekräftige Namen. Kürzen Sie nicht ab (es sei denn, es geht um Mathematik): Ihre Variablennamen werden ihre Absicht verraten. Wählen Sie Namen, die leicht auszusprechen und zu finden sind.
• Während Variablen mit nur einem Buchstaben für Schleifen und mathematische Ausdrücke in Ordnung sind, sollten sie in anderen Situationen nicht abgekürzt werden. Die Klarheit ist wichtiger als jede Zeitersparnis durch das Weglassen einiger Vokale.
• Für ein schnelles Prototyping können Sie vorübergehend kurze "Schrott"-Namen verwenden und später zu aussagekräftigeren Namen refaktorisieren.
• Verwenden Sie Pascal Case für öffentliche Felder und Camel Case für private Variablen: Als Alternative zu öffentlichen Feldern können Sie Eigenschaften mit einem öffentlichen "Getter" verwenden (siehe vorherigen und folgenden Abschnitt).
• Vermeiden Sie zu viele Präfixe oder spezielle Kodierungen: Sie können privaten Mitgliedsvariablen einen Unterstrich (_) voranstellen, um sie von lokalen Variablen zu unterscheiden.
• Alternativ können Sie das Schlüsselwort this verwenden, um zwischen Member- und lokalen Variablen im Kontext zu unterscheiden, und das Präfix weglassen. Öffentliche Felder und Eigenschaften haben im Allgemeinen keine Präfixe.
• Einige Styleguides verwenden Präfixe für private Member-Variablen (m_), Konstanten (k_) oder statische Variablen (s_), damit der Name auf den ersten Blick mehr über die Variable verrät.
• Viele Entwickler meiden diese und verlassen sich stattdessen auf den Editor. Allerdings unterstützen nicht alle IDEs die Hervorhebung und Farbkodierung, und einige Tools können überhaupt keinen umfangreichen Kontext anzeigen. Berücksichtigen Sie dies, wenn Sie entscheiden, wie (oder ob) Sie die Präfixe gemeinsam im Team anwenden werden.
• Geben Sie konsequent Modifikatoren für die Zugriffsebene an (oder lassen Sie sie weg): Wenn Sie den Zugriffsmodifikator weglassen, nimmt der Compiler an, dass die Zugriffsebene privat sein sollte. Das funktioniert gut, aber seien Sie konsequent, wenn Sie den Standardzugriffsmodifikator weglassen.
• Denken Sie daran, dass Sie protected verwenden müssen, wenn Sie dies später in einer Unterklasse wünschen.

Enums sind spezielle Wertetypen, die durch eine Reihe von benannten Konstanten definiert sind. Standardmäßig sind die Konstanten ganze Zahlen, die von Null an aufwärts zählen.

Verwenden Sie Groß- und Kleinschreibung für Enum-Namen und -Werte. Sie können öffentliche Enums außerhalb einer Klasse platzieren, um sie global zu machen. Verwenden Sie für den Enum-Namen ein Singular-Substantiv.

Anmerkung: Bitweise Enums, die mit dem System.FlagsAttribut gekennzeichnet sind, bilden die Ausnahme von dieser Regel. Diese werden in der Regel im Plural geschrieben, da sie für mehr als einen Typ stehen.

Befolgen Sie diese Standardregeln bei der Benennung Ihrer Klassen und Schnittstellen:

Verwenden Sie Substantive in Kleinschreibung für Klassennamen: So bleiben Ihre Klassen organisiert.

Wenn Sie ein MonoBehaviour in einer Datei haben, muss der Name der Quelldatei übereinstimmen: Sie können andere interne Klassen in der Datei haben, aber es sollte nur ein MonoBehaviour pro Datei existieren.

Schnittstellen-Namen mit einem großen "I" voranstellen: Geben Sie anschließend ein Adjektiv an, das die Funktionalität beschreibt.

In C# wird jeder ausgeführte Befehl im Kontext einer Methode ausgeführt.

Methoden führen Aktionen aus, daher sollten Sie diese Regeln anwenden, um sie entsprechend zu benennen:

Beginnen Sie den Namen mit einem Verb: Bei Bedarf Kontext hinzufügen (z. B. GetDirection, FindTarget usw.)

Verwenden Sie bei Parametern Groß- und Kleinschreibung: Formatieren Sie die an die Methode übergebenen Parameter wie lokale Variablen.

Methoden, die bool zurückgeben, sollten Fragen stellen: Ähnlich wie bei den booleschen Variablen selbst wird den Methoden ein Verb vorangestellt, wenn sie eine wahr-falsch-Bedingung zurückgeben. Damit werden sie in Form einer Frage formuliert (z. B. IsGameOver, HasStartedTurn).

Anmerkung: Die Begriffe "Funktion" und "Methode" werden in der Unity-Entwicklung oft synonym verwendet. Da man in C# jedoch keine Funktion schreiben kann, ohne sie in eine Klasse einzubinden, ist "Methode" der richtige Begriff.

Ereignisse in C# implementieren das Beobachtermuster. Dieses Software-Entwurfsmuster definiert eine Beziehung, in der ein Objekt, das Subjekt (oder der Herausgeber), eine Liste von abhängigen Objekten, die Beobachter (oder Abonnenten) genannt werden, benachrichtigen kann. So kann das Subjekt Zustandsänderungen an seine Beobachter übermitteln, ohne die beteiligten Objekte eng zu koppeln.

Es gibt mehrere Benennungsschemata für Ereignisse und die damit verbundenen Methoden im Subjekt und bei den Beobachtern. Probieren Sie die Praktiken in den folgenden Abschnitten aus.

Benennen Sie das Ereignis mit einer Verbphrase. Achten Sie darauf, dass Sie eine auswählen, die die Zustandsänderung genau wiedergibt.

Verwenden Sie das Partizip Präsens oder Präteritum, um den Stand der Dinge als vorher oder nachher anzugeben. Geben Sie zum Beispiel "OpeningDoor" für ein Ereignis vor dem Öffnen einer Tür und "DoorOpened" für ein Ereignis danach an.

Verwenden Sie den System.Action-Delegaten für Ereignisse. In den meisten Fällen wird die Aktion<T> Delegat die für das Gameplay benötigten Ereignisse verarbeiten.

Sie können bis zu 16 Eingabeparameter unterschiedlichen Typs mit einem Rückgabetyp von void übergeben. Die Verwendung des vordefinierten Delegaten spart Code.

Anmerkung: Sie können auch den EventHandler oder verwenden. EventHandler<TEventArgs> Delegaten verwenden. Einigen Sie sich im Team darauf, wie jeder einzelne Veranstaltungen durchführen soll.

Stellen Sie der Methode zum Auslösen von Ereignissen (im Betreff) den Zusatz "On" voran. Das Subjekt, das das Ereignis aufruft, tut dies in der Regel über eine Methode mit dem Präfix "On" (z. B. "OnOpeningDoor" oder "OnDoorOpened").

Stellen Sie der Ereignisbehandlungsmethode (im Beobachter) den Namen des Subjekts und einen Unterstrich (_) voran. Wenn das Thema "GameEvents" heißt, können Ihre Beobachter eine Methode namens "GameEvents_OpeningDoor" oder "GameEvents_DoorOpened" haben.

Entscheiden Sie sich für ein einheitliches Benennungsschema für Ihr Team und setzen Sie diese Regeln in Ihrem Style Guide um.

Anmerkung: Diese "Ereignisbehandlungsmethode" ist nicht zu verwechseln mit dem EventHandler-Delegat.

Erstellen Sie nur bei Bedarf benutzerdefinierte EventArgs. Wenn Sie benutzerdefinierte Daten an Ihr Ereignis übergeben müssen, erstellen Sie einen neuen Typ von EventArgs, entweder geerbt von System.EventArgs oder von einer benutzerdefinierten Struktur.

Verwenden Sie Namespaces, um sicherzustellen, dass Ihre Klassen, Schnittstellen, Enums usw. nicht mit bereits vorhandenen Klassen aus anderen Namespaces oder dem Global Namespace in Konflikt geraten. Namespaces können auch Konflikte mit Assets von Drittanbietern aus dem Unity Asset Store oder anderen Testszenen verhindern, die nicht Teil der endgültigen Version des Projekts sein werden.

Bei der Anwendung von Namespaces:

Verwenden Sie Groß- und Kleinschreibung ohne Sonderzeichen oder Unterstriche.

Fügen Sie eine using-Anweisung am Anfang der Datei hinzu, um die wiederholte Eingabe des Namespace-Präfixes zu vermeiden.

Erstellen Sie auch Unter-Namensräume. Verwenden Sie den Punkt(.)-Operator, um die Namensstufen abzugrenzen, so dass Sie Ihre Skripte in hierarchische Kategorien einteilen können. Sie können zum Beispiel "MyApplication.GameFlow", "MyApplication.AI", "MyApplication.UI" usw. erstellen, um verschiedene logische Komponenten Ihres Spiels zu speichern.

Im Code werden diese Klassen jeweils als Enemy.Controller1 und Enemy.Controller2 bezeichnet. Fügen Sie eine using-Zeile hinzu, um sich die Eingabe des Präfixes zu ersparen (z. B. using Enemy;).

Wenn der Compiler die Klassennamen Controller1 und Controller2 findet, versteht er, dass Sie Enemy.Controller1 und Enemy.Controller2 meinen.

Wenn das Skript auf Klassen mit demselben Namen aus verschiedenen Namespaces verweisen muss, verwenden Sie das Präfix, um sie zu unterscheiden. Wenn Sie beispielsweise eine Controller1- und eine Controller2-Klasse im Player-Namespace haben, können Sie Player.Controller1 und Player.Controller2 ausschreiben, um Konflikte zu vermeiden. Andernfalls wird der Compiler einen Fehler melden.