Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Remarque
Ce contenu est réimprimé avec l’autorisation de Pearson Education, Inc. tiré de Lignes directrices de conception de framework : Conventions, Idiomes et Modèles pour les bibliothèques .NET réutilisables, 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 générales d’affectation de noms qui concernent le choix des mots, des instructions sur l’utilisation d’abréviations et d’acronymes, ainsi que des recommandations sur la façon d’éviter d’utiliser des noms spécifiques à la langue.
Choix des mots
✔️ Choisissez des noms d’identificateurs lisibles facilement.
Par exemple, une propriété nommée HorizontalAlignment est plus lisible en anglais que AlignmentHorizontal.
✔️ Favorisez la lisibilité par rapport à la concision.
Le nom de la propriété CanScrollHorizontally est préférable à ScrollableX, qui est une référence obscure à l’axe X.
❌ NE PAS utiliser de traits de soulignement, de traits d’union ou d’autres caractères nonphanumériques.
❌ N’utilisez PAS la notation hongroise.
❌ ÉVITEz d’utiliser des identificateurs qui entrent en conflit avec des mots clés de langages de programmation largement utilisés.
Selon la règle 4 de common language specification (CLS), toutes les langues conformes doivent fournir un mécanisme qui permet d’accéder à des éléments nommés qui utilisent un mot clé de cette langue comme identificateur. C#, par exemple, utilise le signe @ comme mécanisme d’échappement dans ce cas. Toutefois, 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 seule sans elle.
Utilisation d’abréviations et d’acronymes
❌ NE PAS utiliser d’abréviations ou de contractions dans le cadre des noms d’identificateurs.
Par exemple, utilisez GetWindow plutôt que GetWin.
❌ NE PAS utiliser d’acronymes qui ne sont pas largement acceptés, et même s’ils le sont, uniquement si nécessaire.
Éviter les noms spécifiques aux langages
✔️ Utilisez des noms sémantiquement intéressants plutôt que des mots clés spécifiques au langage pour les noms de types.
Par exemple, GetLength est un meilleur nom que GetInt.
✔️ Utilisez un nom de type CLR générique, plutôt qu’un nom spécifique au langage, dans les rares cas où un identificateur n’a aucune signification sémantique au-delà de son type.
Par exemple, une méthode convertissant en Int64 devrait être nommée ToInt64, et non ToLong (car Int64 est un nom CLR pour l’alias long spécifique à C#). Le tableau suivant présente plusieurs types de données de base à l’aide des noms de types CLR (ainsi que les noms de types correspondants pour C#, Visual Basic et C++).
| C# | Visual Basic | C++ | CLR |
|---|---|---|---|
| sbyte | SByte | char | SByte |
| octet | d’octets | caractères non signés | d’octets |
| courte | Court | courte | Int16 |
| ushort | UInt16 | courte non signée | UInt16 |
| Int | Entier | Int | Int32 |
| uint | UInt32 | int non signé | UInt32 |
| long | Long | __int64 | Int64 |
| ulong | UInt64 | __int64 non signé | UInt64 |
| flotter | Seul | flotter | Seul |
| double | Double | double | Double |
| Bool | Booléen | Bool | Booléen |
| char | Caractère | wchar_t | Caractère |
| chaîne de caractères | Chaîne | Chaîne | Chaîne |
| objet | Objet | Objet | Objet |
✔️ Utilisez un nom commun, tel que value ou item, plutôt que de répéter le nom de type, dans les rares cas où un identificateur n’a pas de signification sémantique et que le type du paramètre n’est pas important.
Affectation de noms aux 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.
Cela vous aidera à la découverte lors de la navigation dans la documentation ou à l’aide d’IntelliSense. L’ancienne version de l’API sera organisée à proximité des nouvelles API, car la plupart des navigateurs et IntelliSense affichent des identificateurs par ordre alphabétique.
✔️ ENVISAGEZ d’utiliser un identificateur nouveau, 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, en particulier si le nom existant de l’API est le seul nom logique (c’est-à-dire s’il s’agit d’une norme du secteur) et si l’ajout d’un suffixe explicite (ou la modification du nom) n’est pas une option appropriée.
❌ N’utilisez PAS le suffixe « Ex » (ou un suffixe similaire) pour qu’un identificateur le distingue 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 existante existe ; ne le faites pas pour les nouvelles API avec uniquement une version 64 bits.
Portions © 2005, 2009 Microsoft Corporation. Tous les droits réservés.
Réimprimé par l’autorisation de Pearson Education, Inc. tiré de Framework Design Guidelines : Conventions, Idioms et Patterns pour les bibliothèques .NET réutilisables, 2e édition par Krzysztof Cwalina et Brad Abrams, publié le 22 octobre 2008 par Addison-Wesley Professional dans le cadre de la Série de développement Microsoft Windows.