Il y a un aspect du langage C# qui n’est pas assez discuté entre programmeurs. Pour chacun des types natifs du framework .NET, il y a un alias qui le représente. Par exemple, System.Double est alliacé par double. Ce mécanisme permet d’imiter le fonctionnement de certains langages comme C++ où il y a la notion de types primitifs.
Alors, pour le compilateur, il n’y a pas de différence entre System.Int32 et int. C’est voulu ainsi. Ce mécanisme est tellement à la base de .NET que j’apprends même quelque chose à certains d’entre vous. Il n’y a pas de mal à cela.
Du moins, je crois que c’est un détail qui est, en soi, très mineur. Cependant, si vous avez un souci du détail comme le mien, vous vous êtes déjà posé la question. Je ne suis pas le seul!
Si je vous demande si vous êtes du type (ha!) utiliser le mot clé ou l’alias de type, vous dites quoi? Concrètement, est-ce que vous écrivez string.IsNullOrEmpty() ou String.IsNullOrEmpty()?
Je vous l’ai dit, c’est vraiment mineur comme point. D’un point de vue du code, ce n’est pas un problème. Toutefois, je sais que c’est un irritant visuel pour une majorité d’entre vous, peu importe votre camp. J’en suis certain.
Les opinions suivent trois courants:
- Le type concret ou rien (Double, Int32, String, etc.)
- Alias sauf pour les extensions (double, String.IsNullOrEmpty(), Float.Parse(), etc.)
- Alias ou rien du tout (double, int, string, etc.)
Pour ma part, je suis dans la troisième option. Je n’ai pas vraiment d’argument qu’autre que j’ai toujours codé ainsi en C#. C’est assez faible comme argument, n’est-ce pas? Mon deuxième argument serait que d’utiliser l’alias permet de déclarer l’intention de faire référence aux méthodes et fonctionnalités de ce qui serait le type primitif en question.
Alternativement, j’ai le réflexe de me tourner vers les standards de nomenclature du Framework .NET tel que documenté dans la MSDN. Je dois dire qu’il y a place à de l’interprétation selon le contexte. Voici l’état des choses.
Dans General Naming Conventions, il est mentionné la chose suivante: « ✓ DO use a generic CLR type name, rather than a language-specific name, in the rare cases when an identifier has no semantic meaning beyond its type. » Cela veut donc dire qu’une méthode devrait se nommer ToInt64 et non pas ToLong pour éviter de la confusion.
Ça, c’est pour un cas de nom de méthode. En particulier dans le cas du framework .NET où des développeurs utilisant différents langages seront amenés à consommer l’API. Si vous augmentez une fonctionnalité du Framework, c’est une bonne idée de rester en ligne avec cette recommandation.
Cependant, dans les exemples de la même section, il y a des extraits de code utilisant des alias à profusion. Alors, même au niveau de .NET c’est flou. De plus, comme Phil Haack le mentionne, l’équipe de développement de CoreFX a exprimé clairement une préférence envers l’utilisation des alias dans son guide de style de développement.
Avec cette information en main, quoi penser? Je pense vraiment qu’il y a une tendance à utiliser les alias qui sont associés aux différents types déclarés sous le namespace System.
L’essentiel à retenir à ce sujet est qu’il s’agit principalement d’un exercice de style. Dans tous les cas, il s’agit d’un point à discuter en équipe si ce n’est pas déjà fait. Par exemple, dans mon cas, il s’agit d’une règle de reformatage qui est automatiquement appliquée par ReSharper.
Tous les membres de l’équipe l’utilisent, alors tout va bien.
French Coding 
