Bien qu'il n'y ait peut-être pas une seule bonne façon de formater votre code C#, s'accorder sur un style cohérent au sein de votre équipe peut aboutir à un code plus propre, plus lisible et évolutif. Cette page offre des conseils et des considérations clés à garder à l'esprit pour vos classes, méthodes et commentaires lors de la création de votre propre guide de style.
Remarque: Les recommandations partagées ici sont basées sur celles fournies par Microsoft. Les meilleures règles de guide de style de code sont celles qui répondent aux besoins de votre équipe.
Vous pouvez trouver un exemple de guide de style de code ici ou télécharger l'e-book complet, Utilisez un guide de style C# pour un code de jeu propre et évolutif (édition Unity 6).
Avec la nomination, le formatage aide à réduire les conjectures et améliore la clarté du code. En suivant un guide de style standardisé, les revues de code deviennent moins une question de l'apparence du code et plus une question de ce qu'il fait.
Omettez, développez ou modifiez ces règles d'exemple pour répondre aux besoins de votre équipe.
Dans tous les cas, considérez comment votre équipe mettra en œuvre chaque règle de formatage et faites ensuite en sorte que tout le monde l'applique uniformément. Reportez-vous au style de votre équipe pour résoudre toute divergence.
Considérez chacune des suggestions de formatage de code suivantes lors de la configuration de votre guide de style de développement Unity.
Une propriété fournit un mécanisme flexible pour lire, écrire ou calculer des valeurs de classe. Les propriétés se comportent comme si elles étaient des variables membres publiques, mais en fait, ce sont des méthodes spéciales appelées accessors. Chaque propriété a une méthode get et set pour accéder à un champ privé, appelé un backing field.
De cette manière, la propriété encapsule les données, les cachant des modifications indésirables par l'utilisateur ou des objets externes. Le getter et le setter ont chacun leur propre modificateur d'accès, permettant à votre propriété d'être en lecture-écriture, en lecture seule ou en écriture seule.
Vous pouvez également utiliser les accessors pour valider ou convertir les données (par exemple, vérifier que les données correspondent à votre format préféré ou changer une valeur en une unité particulière).
La syntaxe des propriétés peut varier, donc votre guide de style devrait définir comment les formater. Utilisez ces conseils pour garder les propriétés cohérentes dans votre code.
Utilisez des propriétés à corps d'expression pour des propriétés en lecture seule sur une seule ligne (=>): Cela renvoie le champ de soutien privé.
Tout le reste utilise l'ancien { get; set; } syntaxe: Si vous souhaitez simplement exposer une propriété publique sans spécifier de champ de soutien, utilisez la Propriété auto-implémentée. Appliquez la syntaxe à corps d'expression pour les accesseurs set et get. N'oubliez pas de rendre le setter privé si vous ne souhaitez pas donner d'accès en écriture. Alignez la fermeture avec l'accolade d'ouverture pour les blocs de code multi-lignes.
La sérialisation de script est le processus automatique de transformation des structures de données ou des états d'objet en un format que Unity peut stocker et reconstruire plus tard. Pour des raisons de performance, Unity gère la sérialisation différemment que dans d'autres environnements de programmation.
Les champs sérialisés apparaissent dans l'Inspecteur, mais vous ne pouvez pas sérialiser des champs statiques, constants ou en lecture seule. Ils doivent être soit publics, soit marqués avec l'attribut [SerializeField]. Unity ne sérialise que certains types de champs, alors référez-vous à la page de documentation pour l'ensemble complet des règles de sérialisation.
Observez quelques directives de base lors de l'utilisation de champs sérialisés :
Référencez cette classe sérialisable depuis une autre classe. Les variables résultantes apparaissent dans des unités réductibles dans l'Inspecteur.
Il existe deux styles d'indentation courants en C# :
Il existe également des variations sur ces styles d'indentation. Les exemples de ce guide utilisent le style Allman des Directives de conception du Framework Microsoft. Peu importe lequel vous choisissez en équipe, assurez-vous que tout le monde suit le même style d'indentation et de accolades.
L'indentation est généralement de deux ou quatre espaces. Faites en sorte que tout le monde dans votre équipe s'accorde sur un paramètre dans vos préférences d'éditeur sans déclencher une guerre de flammes sur les onglets contre les espaces. Notez que Visual Studio offre l'option de convertir les onglets en espaces.
Dans Visual Studio (Windows), accédez à Outils > Options > Éditeur de texte > C# > Onglets.
Sur Visual Studio pour Mac, accédez à Préférences > Code source > Code source C#. Sélectionnez le style de texte pour ajuster les paramètres.
N'omettez pas les accolades - même pas pour des instructions sur une seule ligne. Les accolades augmentent la cohérence, ce qui rend votre code plus facile à lire et à maintenir. Dans cet exemple, les accolades séparent clairement l'action, DoSomething, de la boucle.
Si plus tard vous devez ajouter une ligne de débogage ou exécuter DoSomethingElse, les accolades seront déjà en place. Maintenir la clause sur une ligne séparée vous permet d'ajouter facilement un point d'arrêt.
Ne retirez pas les accolades des instructions multilignes imbriquées. Retirer les accolades dans ce cas ne générera pas d'erreur, mais risque de causer de la confusion. Appliquez des accolades pour plus de clarté, même si elles sont optionnelles. Les accolades garantissent également que les modifications, telles que l'ajout d'une nouvelle logique, peuvent être effectuées en toute sécurité sans avoir besoin de refactoriser la structure environnante.
Le formatage peut varier, alors documentez les préférences de votre équipe dans votre guide de style et standardisez vos switch déclarations en conséquence.
Voici un exemple où vous indentez les instructions de cas. Il est généralement recommandé d'inclure également un cas par défaut. Même si le cas par défaut n'est pas nécessaire (par exemple, dans les cas où toutes les possibilités sont couvertes), en inclure un garantit que le code est prêt à gérer des valeurs inattendues.
Quelque chose d'aussi simple que l'espacement peut améliorer l'apparence de votre code à l'écran. Vos préférences de formatage personnelles peuvent varier, mais essayez les suggestions suivantes pour améliorer la lisibilité.
Ajoutez des espaces pour diminuer la densité du code.L'espace supplémentaire peut donner un sens de séparation visuelle entre les parties d'une ligne, améliorant la lisibilité.
Utilisez un seul espace après une virgule entre les arguments de fonction.
N'ajoutez pas d'espace après la parenthèse et les arguments de fonction.
N'utilisez pas d'espaces entre un nom de fonction et une parenthèse.
Autant que possible, évitez les espaces à l'intérieur des crochets.
Utilisez un seul espace avant les conditions de contrôle de flux et ajoutez un espace entre l'opérateur de comparaison de flux et les parenthèses.
Utilisez un seul espace avant et après les opérateurs de comparaison.
Gardez les lignes courtes. Considérez l'espace horizontal : Décidez d'une largeur de ligne standard (80-120 caractères). Divisez une longue ligne en déclarations plus petites plutôt que de la laisser déborder.
Maintenez l'indentation/la hiérarchie : Indentez votre code pour augmenter la lisibilité.
N'utilisez pas l'alignement des colonnes sauf si nécessaire pour la lisibilité : Ce type d'espacement aligne les variables mais peut rendre difficile l'association du type avec le nom.
L'alignement des colonnes, cependant, peut être utile pour les expressions bit à bit ou les structures avec beaucoup de données. Soyez simplement conscient que cela peut créer plus de travail pour vous pour maintenir l'alignement des colonnes à mesure que vous ajoutez plus d'éléments. Certains auto-formateurs pourraient également changer quelle partie de la colonne est alignée.
Vous pouvez également utiliser l'espacement vertical à votre avantage. Gardez les parties liées du script ensemble et utilisez des lignes vides à votre avantage. Essayez ces suggestions pour organiser votre code de haut en bas :
Gardez cela au minimum et notez dans votre guide de style où cela s'applique.
Utilisation des régions dans votre code
La directive #region vous permet de réduire et de cacher des sections de code dans les fichiers C#, rendant les grands fichiers plus gérables et plus faciles à lire.
Cependant, si vous suivez les conseils généraux pour les Classes de ce guide, la taille de votre classe devrait être gérable et la directive #region superflue. Divisez votre code en classes plus petites au lieu de cacher des blocs de code derrière des régions. Vous serez moins enclin à ajouter une région si le fichier source est court.
Remarque: De nombreux développeurs considèrent les régions comme des odeurs de code ou des anti-modèles. Décidez en équipe de quel côté du débat vous vous situez.
Ne désespérez pas si ces règles de formatage semblent écrasantes. Les IDE modernes rendent efficace la mise en place et l'application de celles-ci. Vous pouvez créer un modèle de règles de formatage et ensuite convertir vos fichiers de projet d'un coup.
Pour configurer les règles de formatage pour l'éditeur de script :
Si à tout moment vous souhaitez forcer votre fichier de script à se conformer au guide de style :
Sur Windows, vous pouvez également partager vos paramètres d'éditeur depuis Outils > Importer et exporter des paramètres. Exportez un fichier avec le formatage de code C# du guide de style, puis demandez à chaque membre de l'équipe d'importer ce fichier.
Visual Studio facilite le suivi du guide de style. Le formatage devient alors aussi simple que d'utiliser une combinaison de touches.
Remarque : Vous pouvez configurer un fichier EditorConfig au lieu d'importer et d'exporter les paramètres de Visual Studio. Cela vous permet de partager le formatage plus facilement entre différents IDE, et cela a l'avantage supplémentaire de fonctionner avec le contrôle de version. Voir les options de règles de style de code .NET pour plus d'informations.
Bien que cela ne soit pas spécifique au code propre, assurez-vous de consulter 10 façons d'accélérer votre flux de travail de programmation dans Unity avec Visual Studio. Le code propre est beaucoup plus facile à formater et à refactoriser si vous appliquez ces conseils de productivité.
Pour configurer un fichier .editorconfig dans Visual Studio Code, suivez ces étapes :
Voici un exemple de configuration pour C# :
# fichier EditorConfig le plus haut
root = true
# nouvelles lignes de style Unix avec une nouvelle ligne à la fin de chaque fichier
[*]
end_of_line = lf
insert_final_newline = true
# indentation de 4 espaces
[*.cs]
indent_style = space
indent_size = 4
charset = utf-8
trim_trailing_whitespace = true
# Indentation par tabulation pour les Makefiles
[Makefile]
indent_style = tab
# Paramètres spécifiques pour les fichiers JSON
[*.json]
indent_style = space
indent_size = 2
En savoir plus sur les conventions de nommage ici ou consultez le livre électronique complet. Vous pouvez également explorer notre exemple de guide de style de code détaillé.
