Je viens d'installer une version d'essai de ReSharper et l'une des premières choses que j'ai remarquées est qu'elle suggère toujours de remplacer les variables locales explicitement typées par des variables implicitement typées, par exemple:
public string SomeMethod(int aParam)
{
int aNumber = SomeOtherMethod(aParam);
// should be changed to:
var aNumber = SomeOtherMethod(aParam);
}
Je pense que les variables explicitement typées sont plus lisibles (plus explicites).
Que pensez-vous de la suggestion de ReSharper? Y a-t-il un avantage à utiliser des variables typées implicitement? Quand utilisez-vous les variables implicites/explicites?
Personnellement, j'utilise uniquement "var" lorsque je peux clairement distinguer le type de variable en lisant simplement la déclaration, par exemple:
var someVariable = new List<int>();
Dans l'exemple ci-dessus, il est évident que "var" fait référence à "List <int>".
Je n'aime pas utiliser "var" quand je dois aller à une définition de méthode pour savoir ce que le type de variable "var" représente ou en ayant à compter sur visual studio intelli-popup ou quoi que ce soit qui est appelé, par exemple ceci dans ça ne me va pas:
var someVaraible = SomeMethod();
Je veux dire, quelle est la fonction "SomeMethod" censée retourner? Pouvez-vous le dire simplement en regardant la ligne de code? Non, vous ne pouvez pas, c'est pourquoi j'évite d'utiliser "var" dans ces situations.
Il y a beaucoup de discussions à ce sujet, mais je pense que tout se résume au goût personnel, tout comme l'utilisation du mot-clé "this" presque partout.
Je personnellement préfère les variables explicitement typées, mais lorsque vous utilisez des collections génériques imbriquées, les choses peuvent devenir plus lisibles en utilisant une variable implicitement typée. Regarder:
Dictionary<string, Dictionary<string, string>> myDictionary = new Dictionary<string, Dictionary<string, string>>();
contre:
var myDictionary = new Dictionary<string, Dictionary<string, string>>();
EDIT: ce sujet SO couvre le même sujet, avec quelques bonnes réponses: Que faut-il utiliser: var ou type de nom d'objet?
EDIT2: Travaillant beaucoup avec async de nos jours, je trouve que l'utilisation de variables de type explicité peut parfois éviter des bugs désagréables. Considérez cet exemple stupide où vous souhaitez renvoyer l'ID d'un utilisateur. Considérez également que GetUserAsync
renvoie un Task<User>
. Si vous utilisez des variables typées implicitement, vous finirez par utiliser quelque chose comme ceci:
public long GetUserId()
{
var user = GetUserAsync();
return user.Id;
}
Cela compile, mais c'est faux. 'utilisateur' est en fait un Task<User>
. Et il compile comme Task
a également une propriété Id
. Dans ce cas, on retournerait accidentellement l'ID d'une tâche au lieu de l'utilisateur.
public long GetUserId()
{
User user = GetUserAsync();
return user.Id;
}
Ce qui précède ne se compile pas, car le compilateur se plaindra que vous ne pouvez pas caster une tâche vers un utilisateur. L'ajout du mot clé await
résout bien sûr ce problème.
J'ai déjà eu ça une fois :-)
Juste au cas où certains ne l'auraient pas encore remarqué, vous pouvez facilement changer les "suggestions" dans Reshaper (Reshaper -> Options -> Langues -> Actions de contexte -> "Remplacer la spécification de type explicite par" var "").
Personnellement, je préfère avoir des spécifications de type explicites partout, mais je ne suis pas trop pointilleux à ce sujet.
Il est parfois plus facile de taper le pseudo-mot clé var qu'un nom de type énorme, surtout si un générique peut être impliqué. Cependant, vous devez savoir qu'ils sont fonctionnellement identiques. Il n'y a aucune différence de performance ou quoi que ce soit de toute façon. Le compilateur dérive le type du côté droit de l'affectation et remplace var par ce type. Cela ne se produit pas au moment de l'exécution comme une variante VB.
FWIW, le mot-clé var est clairement lisible dans de nombreux cas. En particulier si...
Le côté droit de l'affectation est une expression constructeur.
var map = new Dictionary> ();
Les variables locales ont de bons noms.
HTH