Conventions générales d'affectation de noms
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. à partir des Instructions de conception d’une infrastructure : conventions, idiomes et modèles des bibliothèques réutilisables .NET, 2ème édition. Cette édition a été publiée en 2008, et le livre a été entièrement révisé dans la troisième édition. Certaines informations de cette page peuvent être obsolètes.
Cette section décrit les conventions de nommage générales relatives au choix des mots, les instructions sur l’utilisation des abréviations et acronymes, ainsi que les recommandations pour éviter les noms propres à un langage.
Choix des mots
✔️ CHOISISSEZ des noms d’identificateur facilement lisibles.
Par exemple, une propriété nommée HorizontalAlignment est plus lisible en anglais que AlignmentHorizontal.
✔️ FAVORISEZ la lisibilité plutôt que la concision.
Le nom de propriété CanScrollHorizontally fonctionne mieux que ScrollableX (référence obscure à l’axe des abscisses).
❌ N’UTILISEZ PAS de traits de soulignement, de traits d’union ou d’autres caractères non alphanumériques.
❌ N’UTILISEZ PAS la notation hongroise.
❌ ÉVITEZ d’utiliser des identificateurs qui entrent en conflit avec les mots clés des langages de programmation largement utilisés.
Selon la règle 4 de la Common Language Specification (CLS), tous les langages conformes doivent fournir un mécanisme qui permet d’accéder aux éléments nommés qui utilisent un mot clé de ce langage en tant qu’identificateur. C#, par exemple, utilise le signe @ comme mécanisme d’échappement dans ce cas. Néanmoins, il est toujours judicieux d’éviter les mots clés courants, car il est beaucoup plus difficile d’utiliser une méthode avec la séquence d’échappement qu’une méthode sans elle.
Utilisation d’abréviations et d’acronymes
❌ N’UTILISEZ PAS d’abréviations ni de contractions dans les noms d’identificateurs.
Par exemple, utilisez GetWindow plutôt que GetWin.
❌ N’UTILISEZ PAS d’acronymes qui ne sont pas largement connus, et même s’ils le sont, utilisez-les uniquement si nécessaire.
Éviter les noms propres à des langages
✔️ UTILISEZ des noms sémantiquement intéressants plutôt que des mots clés spécifiques des langages pour les noms de type.
Par exemple, GetLength fonctionne mieux que GetInt.
✔️ UTILISEZ un nom de type CLR générique plutôt qu’un nom propre à un langage, dans les rares cas où un identificateur n’a aucune signification sémantique au-delà de son type.
Par exemple, une méthode de conversion en Int64 doit être nommée ToInt64, et non ToLong (car Int64 est un nom CLR pour l’alias long propre à C#). Le tableau suivant présente plusieurs types de données de base utilisant des noms de type CLR (ainsi que les noms de type correspondants pour C#, Visual Basic et 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 | nombre entier non signé | UInt32 |
| long | Long | __int64 | Int64 |
| ulong | UInt64 | unsigned __int64 | UInt64 |
| float | Unique | float | Unique |
| double | Double | double | Double |
| bool | Booléen | bool | Booléen |
| char | Char | wchar_t | Char |
| string | Chaîne | Chaîne | Chaîne |
| object | Object | Object | Object |
✔️ UTILISEZ un nom commun, comme value ou item, au lieu de répéter le nom du type, dans les rares cas où un identificateur n’a aucune signification sémantique et où le type du paramètre importe peu.
Nommage des nouvelles versions des API existantes
✔️ UTILISEZ un nom similaire à l’ancienne API lors de la création de nouvelles versions d’une API existante.
Cela permet de mettre en évidence la relation entre les API.
✔️ PRÉFÉREZ ajouter un suffixe plutôt qu’un préfixe pour indiquer une nouvelle version d’une API existante.
La recherche s’en retrouve facilitée lors de la navigation dans la documentation ou de l’utilisation d’IntelliSense. L’ancienne version de l’API sera classée à proximité des nouvelles API, car la plupart des navigateurs et IntelliSense affichent les identificateurs dans l’ordre alphabétique.
✔️ ENVISAGEZ d’utiliser un tout nouveau identificateur, mais significatif, au lieu d’ajouter un suffixe ou un préfixe.
✔️ UTILISEZ un suffixe numérique pour indiquer une nouvelle version d’une API existante, notamment si le nom existant de l’API est le seul nom significatif (c’est-à-dire s’il s’agit d’une norme du secteur) et si l’ajout d’un suffixe significatif (ou la modification du nom) n’est pas une option appropriée.
❌ N’UTILISEZ PAS le suffixe « Ex » (ou un suffixe similaire) pour un identificateur afin de le distinguer d’une version antérieure de la même API.
✔️ UTILISEZ le suffixe « 64 » lors de l’introduction de versions d’API qui fonctionnent sur un entier 64 bits (un entier long) au lieu d’un entier 32 bits. Vous devez uniquement adopter cette approche lorsque l’API 32 bits existe déjà. Ne le faites pas pour les API nouvelles qui ont uniquement une version 64 bits.
Portions © 2005, 2009 Microsoft Corporation. Tous droits réservés.
Réimprimé avec l’autorisation de Pearson Education, Inc. et extrait de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la série sur le développement Microsoft Windows.