Vous ne pouvez pas définir de variables avec des espaces dans le nom, car C# utilise le caractère espace pour séparer les identifiants. Les schémas de casse peuvent atténuer le problème de l'utilisation de noms ou d'expressions composés dans le code source.

Vous trouverez ci-dessous plusieurs conventions de dénomination et de casse bien connues :

Affaire de chameau

Également connu sous le nom de casquettes de chameau, le cas de chameau est la pratique consistant à écrire des phrases sans espaces ni ponctuation, en séparant les mots par une seule lettre majuscule. La toute première lettre est en minuscule.

Généralement, les variables locales et les paramètres de méthode apparaissent en cas de chameau. Par exemple:

examplePlayerController
maxHealthPoints
endOfFile

Cas Pascal

Le cas Pascal est une variante du cas Camel, où la lettre initiale est en majuscule. Utilisez-le pour les noms de classe et de méthode dans le développement Unity. Les champs publics peuvent également être des cas Pascal. Par exemple:

ExamplePlayerController
MaxHealthPoints
EndOfFile

Cas de serpent

Dans ce cas, les espaces entre les mots sont remplacés par un caractère de soulignement. Par exemple:

example_player_controller
max_health_points
end_of_file

Cas de kebab

Ici, les espaces entre les mots sont remplacés par des tirets. Les mots apparaissent alors sur une sorte de « brochette » de caractères tirets. Par exemple:

exemple-joueur-contrôleur
Points de santé maximum
fin de fichier

Le problème avec le cas du kebab est que de nombreux langages de programmation utilisent le tiret comme signe moins. De plus, certaines langues interprètent les nombres séparés par des tirets comme des dates du calendrier.

notation hongroise

Le nom de la variable ou de la fonction indique souvent son intention ou son type. Par exemple:

int iCompteur
chaîne strPlayerName

La notation hongroise est une convention plus ancienne et n'est pas couramment utilisée dans le développement de Unity.

Tenez compte de ces règles pour vos variables et champs :

• Utilisez des noms pour les noms de variables : Les noms de variables doivent être clairs et descriptifs car ils représentent une chose ou un état spécifique. Utilisez un nom pour les nommer, sauf lorsque la variable est de type bool (voir ci-dessous).
• Préfixez les booléens avec un verbe : Ces variables indiquent une valeur vraie ou fausse. Souvent, ils sont la réponse à une question, telle que : Le joueur est-il en train de courir ? Le jeu est-il terminé ?
• Préfixez-les avec un verbe pour rendre leur sens plus apparent. Souvent, cela est associé à une description ou à une condition, par exemple isDead, isWalking, hasDamageMultiplier, etc.
• Utilisez des noms significatifs. N'abrégez pas (sauf si ce sont des mathématiques) : Les noms de vos variables révéleront leur intention. Choisissez des noms faciles à prononcer et à rechercher.
• Bien que les variables à une seule lettre conviennent aux boucles et aux expressions mathématiques, n'abrégez pas dans d'autres situations. La clarté est plus importante que le temps gagné en omettant quelques voyelles.
• Pour un prototypage rapide, vous pouvez utiliser temporairement des noms « indésirables », puis les refactoriser ultérieurement vers des noms plus significatifs.
• Utilisez la casse Pascal pour les champs publics et la casse Camel pour les variables privées : Pour une alternative aux champs publics, utilisez des propriétés avec un « getter » public (voir les sections précédentes et suivantes).
• Évitez trop de préfixes ou d'encodages spéciaux : Vous pouvez préfixer les variables membres privées avec un trait de soulignement (_) pour les différencier des variables locales.
• Vous pouvez également utiliser le mot-clé this pour faire la distinction entre les variables membres et locales dans le contexte et ignorer le préfixe. Les champs et propriétés publics n’ont généralement pas de préfixes.
• Certains guides de style utilisent des préfixes pour les variables membres privées (m_), les constantes (k_) ou les variables statiques (s_), afin que le nom puisse en révéler davantage sur la variable en un coup d'œil.
• De nombreux développeurs les évitent et s’appuient plutôt sur l’éditeur. Cependant, tous les IDE ne prennent pas en charge la mise en surbrillance et le codage couleur, et certains outils ne peuvent pas du tout afficher un contexte riche. Tenez-en compte lorsque vous décidez comment (ou si) vous appliquerez les préfixes ensemble en équipe.
• Spécifiez (ou omettez) les modificateurs de niveau d'accès de manière cohérente : Si vous omettez le modificateur d'accès, le compilateur supposera que le niveau d'accès doit être privé. Cela fonctionne bien, mais soyez cohérent dans la façon dont vous omettez le modificateur d'accès par défaut.
• N'oubliez pas que vous devrez utiliser protected si vous le souhaitez plus tard dans une sous-classe.

Les énumérations sont des types de valeurs spéciales définies par un ensemble de constantes nommées. Par défaut, les constantes sont des nombres entiers, comptant à partir de zéro.

Utilisez la casse Pascal pour les noms et les valeurs d'énumération. Vous pouvez placer des énumérations publiques en dehors d'une classe pour les rendre globales. Utilisez un nom singulier pour le nom de l'énumération.

Note: Les énumérations au niveau du bit marquées avec System.FlagsAttribute sont l'exception à cette règle. Vous les mettez généralement au pluriel car ils représentent plus d’un type.

Suivez ces règles standard lorsque vous nommez vos classes et interfaces :

Utilisez des noms en cas pascal pour les noms de classe : Cela gardera vos cours organisés.

Si vous avez un MonoBehaviour dans un fichier, le nom du fichier source doit correspondre : Vous pouvez avoir d'autres classes internes dans le fichier, mais un seul MonoBehaviour doit exister par fichier.

Préfixez les noms d’interfaces avec un « I » majuscule: Suivez ceci avec un adjectif qui décrit la fonctionnalité.

En C#, chaque instruction exécutée est exécutée dans le contexte d'une méthode.

Les méthodes effectuent des actions, appliquez donc ces règles pour les nommer en conséquence :

Commencez le nom par un verbe: Ajoutez du contexte si nécessaire (par exemple,GetDirection,FindTarget, etc.)

Utilisez Camel Case pour les paramètres : Paramètres de format passés dans la méthode comme des variables locales.

Les méthodes renvoyant bool devraient poser des questions : Tout comme les variables booléennes elles-mêmes, préfixez les méthodes avec un verbe si elles renvoient une condition vrai-faux. Cela les formule sous la forme d'une question (par exemple,IsGameOver,HasStartedTurn).

Note: Les termes « fonction » et « méthode » sont souvent utilisés de manière interchangeable dans le développement de Unity. Cependant, comme vous ne pouvez pas écrire une fonction sans l'incorporer dans une classe en C#, « méthode » est le terme correct.

Les événements en C# implémentent le modèle d'observateur. Ce modèle de conception logicielle définit une relation dans laquelle un objet, le sujet (ou l'éditeur), peut notifier une liste d'objets dépendants appelés observateurs (ou abonnés). Ainsi, le sujet peut diffuser des changements d’état à ses observateurs sans coupler étroitement les objets impliqués.

Plusieurs schémas de dénomination existent pour les événements et leurs méthodes associées chez le sujet et les observateurs. Essayez les pratiques des sections suivantes.

Nommez l’événement avec une phrase verbale. Assurez-vous d’en choisir un qui communique avec précision le changement d’état.

Utilisez le participe présent ou passé pour indiquer l’état des événements comme avant ou après. Par exemple, spécifiez « OpeningDoor » pour un événement avant d'ouvrir une porte et « DoorOpened » pour un événement après.

Utilisez le délégué System.Action pour les événements. Dans la plupart des cas, le délégué Action<T> peut gérer les événements nécessaires au gameplay.

Vous pouvez transmettre jusqu'à 16 paramètres d'entrée de types différents avec un type de retour void. L’utilisation du délégué prédéfini enregistre le code.

Note: Vous pouvez également utiliser les délégués EventHandler ou EventHandler<TEventArgs> . Convenez en équipe de la manière dont chacun doit mettre en œuvre les événements.

Préfixez la méthode de déclenchement d’événement (dans le sujet) avec « On ». Le sujet qui invoque l'événement le fait généralement à partir d'une méthode préfixée par « On » (par exemple, « OnOpeningDoor » ou « OnDoorOpened »).

Préfixez la méthode de gestion des événements (dans l'observateur) avec le nom du sujet et un trait de soulignement (_). Si le sujet est nommé « GameEvents », vos observateurs peuvent avoir une méthode appelée « GameEvents_OpeningDoor » ou « GameEvents_DoorOpened ».

Choisissez un schéma de dénomination cohérent pour votre équipe et implémentez ces règles dans votre guide de style.

Note: Cette « méthode de gestion des événements » ne doit pas être confondue avec le délégué EventHandler.

Créez des EventArgs personnalisés uniquement si nécessaire. Si vous devez transmettre des données personnalisées à votre événement, créez un nouveau type de EventArgs, hérité de System.EventArgs ou d'une structure personnalisée.

Utilisez des espaces de noms pour vous assurer que vos classes, interfaces, énumérations, etc. n'entrent pas en conflit avec celles déjà existantes dans d'autres espaces de noms ou avec l'espace de noms global. Les espaces de noms peuvent également éviter les conflits avec des ressources tierces de Unity Asset Store ou d'autres scènes de test qui ne feront pas partie de la version finale du projet.

Lors de l'application d'espaces de noms :

Utilisez la casse Pascal sans symboles spéciaux ni traits de soulignement.

Ajoutez une directiveusingen haut du fichier pour éviter la saisie répétée du préfixe de l'espace de noms.

Créez également des sous-espaces de noms. Utilisez l'opérateur point(.) pour délimiter les niveaux de nom, vous permettant ainsi d'organiser vos scripts en catégories hiérarchiques. Par exemple, vous pouvez créer « MyApplication.GameFlow », « MyApplication.AI », « MyApplication.UI », etc., pour contenir différents composants logiques de votre jeu.

Dans le code, ces classes sont appelées respectivement Enemy.Controller1 et Enemy.Controller2. Ajoutez une ligne using pour éviter de taper le préfixe (par exemple,en utilisant Enemy ;).

Lorsque le compilateur trouve les noms de classe Controller1 et Controller2, il comprend que vous voulez dire Enemy.Controller1 et Enemy.Controller2.

Si le script doit faire référence à des classes portant le même nom provenant d'espaces de noms différents, utilisez le préfixe pour les différencier. Par exemple, si vous avez une classe Controller1 et Controller2 dans l'espace de noms Player, vous pouvez écrirePlayer.Controller1et Player.Controller2 pour éviter tout conflit. Sinon, le compilateur signalera une erreur.