Noms de classes, de structures et d'interfaces

En général, les noms de types doivent être des groupes nominaux dont le nom est l'entité représentée par le type. Par exemple, Button, Stack et File possèdent tous des noms qui identifient l'entité représentée par le type. Choisissez des noms permettant au développeur d'identifier l'entité ; les noms doivent refléter des scénarios d'usage.

Les règles suivantes s'appliquent à la sélection de noms de types.

Attribuez aux classes, aux interfaces et aux types valeur des noms, des groupes nominaux, accompagnés ou non de qualificatifs, à l'aide de la casse Pascal.

N'attribuez pas de préfixe (la lettre C, par exemple) aux noms de classes.

Les interfaces, qui doivent commencer par la lettre I, représentent l'exception à cette règle.

Envisagez de faire suivre les noms de classes dérivées du nom de la classe de base.

Par exemple, les types .NET Framework qui héritent de Stream se terminent par Stream et les types qui héritent de Exception se terminent par Exception.

Faites précéder les noms d'interfaces du préfixe « I » pour indiquer qu'il s'agit d'un type interface.

Lors de la définition d'une paire classe/interface où la classe représente une implémentation standard de l'interface, assurez-vous que les noms se distinguent uniquement par l'ajout du préfixe « I » au nom de l'interface.

Par exemple, le .NET Framework fournit l'interface IAsyncResult et la classe AsyncResult.

Noms des paramètres de type générique

Les génériques constituent une grande nouveauté du .NET Framework version 2.0. Les règles suivantes permettent de sélectionner des noms corrects pour les paramètres de type générique.

Attribuez aux paramètres de type générique des noms descriptifs, sauf si une seule lettre est suffisamment explicative et si l'ajout d'un nom n'apporte rien.

IDictionary<TKey, TValue> est un exemple d'interface qui respecte cette règle.

Envisagez d'utiliser la lettre T comme nom de paramètre de type pour les types possédant un paramètre de type composé d'une seule lettre.

Ajoutez la lettre T comme préfixe du paramètre de type descriptif.

Envisagez de signaler les contraintes placées sur un paramètre de type dans le nom de paramètre. Par exemple, un paramètre limité à ISession peut être appelé TSession.

Noms des types courants

Les règles suivantes proposent des conventions d'affectation de noms qui aident les développeurs à identifier le scénario d'usage prévu de certaines classes. Lorsque la règle fait référence à des types qui héritent d'un autre type, cela s'applique à tous les héritiers, pas uniquement aux types qui en héritent directement. Par exemple, l'indication « ajouteException le suffixe aux types dont héritez.Exception » signifie que n'importe quel type qui aException dans sa hiérarchie d'héritage doit avoir un nom qui se termineException.

Chacune de ces règles sert également à réserver le suffixe spécifié. Sauf si votre type répond aux critères définis par l'instruction, il ne doit pas utiliser de suffixe. Par exemple, si votre type n'hérite pas directement ou indirectement de Exception, son nom ne doit pas se terminer par Exception.

Ajoutez le suffixe Attribute aux classes d'attributs personnalisés.

ObsoleteAttribute et AttributeUsageAttribute sont des noms de types qui respectent cette règle.

Ajoutez le suffixe EventHandler aux noms des types utilisés dans les événements (par exemple, les types de retour d'un événement C#).

AssemblyLoadEventHandler est un nom de délégué qui respecte cette règle.

Ajoutez le suffixe Callback au nom d'un délégué qui n'est pas un gestionnaire d'événements.

N'ajoutez pas le suffixe Delegate à un délégué.

Ajoutez le suffixe EventArgs aux classes qui étendent System.EventArgs.

Ne créez pas de noms de classes dérivés de la classe System.Enum ; utilisez à la place le mot clé pris en charge par votre langage. Par exemple, en C#, utilisez le mot clé enum.

Ajoutez le suffixe Exception aux types qui héritent de System.Exception.

Ajoutez le suffixe Dictionary aux types qui implémentent System.Collections.IDictionary ou System.Collections.Generic.IDictionary<TKey, TValue>. Notez que System.Collections.IDictionary est un type spécifique de collection, mais cette règle est prioritaire sur les règles plus générales sur les collections présentées ci-après.

Ajoutez le suffixe Collection aux types qui implémentent System.Collections.IEnumerable, System.Collections.ICollection, System.Collections.IList, System.Collections.Generic.IEnumerable<T>, System.Collections.Generic.ICollection<T> ou System.Collections.Generic.IList<T>.

Ajoutez le suffixe Stream aux types qui héritent de System.IO.Stream.

Ajoutez le suffixe Permission aux types qui héritent de System.Security.CodeAccessPermission ou implémentent System.Security.IPermission.

Noms des énumérations

N'utilisez pas de préfixe pour les noms de valeurs d'énumération. Par exemple, n'utilisez pas de préfixe tel que ad pour les énumérations ADO ou rtf pour les énumérations de texte enrichi, etc.

Cette règle implique également de ne pas inclure le nom de type énumération dans les noms de valeurs d'énumération. L'exemple de code suivant illustre l'attribution de noms incorrects aux valeurs d'une énumération.

Public Enum Teams

    TeamsAlpha
    TeamsBeta
    TeamsDelta

End Enum

public  enum Teams
{
    TeamsAlpha,
    TeamsBeta,
    TeamsDelta
}

N'utilisez pas de suffixe Enum pour les types énumération.

N'ajoutez pas de suffixe Flags aux noms des énumérations d'indicateurs.

Utilisez un nom singulier pour une énumération, sauf si ses valeurs représentent des champs de bits.

Utilisez un nom au pluriel pour les énumérations dont les valeurs représentent des champs de bits, également appelées énumérations d'indicateurs.

Portions Copyright 2005 Microsoft Corporation. Tous droits réservés.

Portions Copyright Addison-Wesley Corporation. Tous droits réservés.

Pour plus d'informations sur les règles de conception, consultez « règles de conception d'infrastructure : Conventions idiomes et modèles carnet de bibliothèques réutilisables framework » Krzysztof Cwalina et Brad Abrams, publiés par Addison-Wesley, 2005.

Voir aussi

Autres ressources

Instructions de conception pour le développement de bibliothèques de classes

Instructions relatives aux noms