Utilisation du mot-clé var en C#

Question

Après avoir discuté avec des collègues de l'utilisation du mot-clé "var" en C# 3, je me suis demandé ce que les gens pensaient de l'utilisation appropriée de l'inférence de type via var.

Par exemple, j'ai plutôt paresseusement utilisé var dans des circonstances douteuses, par exemple :-.

foreach(var item in someList) { // ... } // Type of 'item' not clear.
var something = someObject.SomeProperty; // Type of 'something' not clear.
var something = someMethod(); // Type of 'something' not clear.

Les utilisations plus légitimes du var sont les suivantes:-

var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.

Il est intéressant de noter que LINQ semble être un peu une zone grise, par exemple :-.

var results = from r in dataContext.SomeTable
              select r; // Not *entirely clear* what results will be here.

Le résultat est clair : il s'agit d'un type qui implémente IEnumerable, mais ce n'est pas aussi évident qu'une var déclarant un nouvel objet.

C'est encore pire lorsqu'il s'agit de LINQ to objects, par exemple :-.

var results = from item in someList
              where item != 3
              select item;

Ce n'est pas mieux que l'équivalent foreach(var item in someList) { // ... } équivalent.

Il y a un réel problème de sécurité de type ici - par exemple, si nous devions placer les résultats de cette requête dans une méthode surchargée qui accepte IEnumerable<int> et IEnumerable<double>, l'appelant pourrait par inadvertance passer dans le mauvais type.

var fait maintenir un typage fort, mais la question est vraiment de savoir s'il est dangereux que le type ne soit pas immédiatement apparent lors de la définition, ce qui est amplifié lorsque les surcharges signifient que des erreurs de compilation peuvent ne pas être émises lorsque vous passez involontairement le mauvais type à une méthode.

Answer 1

Je pense toujours var peut rendre le code plus lisible dans certains cas. Si j'ai une classe Client avec une propriété Commandes, et que je veux l'affecter à une variable, je vais simplement faire ceci :

var orders = cust.Orders;

Je me fiche de savoir si Customer.Orders est IEnumerable<Order> , ObservableCollection<Order> ou BindingList<Order> - tout ce que je veux, c'est garder cette liste en mémoire pour pouvoir l'itérer ou obtenir son nombre ou autre chose plus tard.

Comparez la déclaration ci-dessus avec :

ObservableCollection<Order> orders = cust.Orders;

Pour moi, le nom du type n'est que du bruit. Et si je reviens en arrière et décide de changer le type de Customer.Orders plus tard (disons de ObservableCollection<Order> a IList<Order> ), je dois également modifier cette déclaration, ce que je n'aurais pas eu à faire si j'avais utilisé var en premier lieu.

Answer 2

J'utilise var de manière extensive. On a critiqué le fait que cela réduisait la lisibilité du code, mais aucun argument ne vient étayer cette affirmation.

Certes, cela peut signifier que l'on ne sait pas exactement à quel type on a affaire. Et alors ? C'est en fait l'intérêt d'une conception découplée. Lorsqu'il s'agit d'interfaces, vous devez impérativement no s'intéresse au type d'une variable. var va beaucoup plus loin, c'est vrai, mais je pense que l'argument reste le même du point de vue de la lisibilité : Le programmeur ne devrait pas être intéressé par le type de la variable mais plutôt par ce qu'une variable fait . C'est pourquoi Microsoft appelle également l'inférence de type "typage de canard".

Alors, que fait une variable quand je la déclare en utilisant var ? Facile, il fait ce qu'IntelliSense me dit de faire. Tout raisonnement sur le C# qui ignore l'IDE est en deçà de la réalité. En pratique, tout code C# est programmé dans un IDE qui supporte IntelliSense.

Si j'utilise un var et que je ne sais plus à quoi sert la variable, il y a quelque chose de fondamentalement faux dans mon code. var n'est pas la cause, elle ne fait que rendre les symptômes visibles. Ne blâmez pas le messager.

Maintenant, l'équipe C# a publié une directive de codage indiquant que var devrait sólo peut être utilisé pour capturer le résultat d'une instruction LINQ qui crée un type anonyme (car ici, nous n'avons pas de réelle alternative à l'option var ). Eh bien, tant pis. Tant que l'équipe C# ne me donne pas d'argument solide pour cette directive, je vais l'ignorer car, selon mon opinion professionnelle et personnelle, c'est de la pure foutaise. (Désolé, je n'ai pas de lien vers la ligne directrice en question).

En fait, il y a quelques (superficiellement) de bonnes explications sur pourquoi vous ne devriez pas utiliser var mais je continue à croire qu'ils ont largement tort. Prenons l'exemple de la "facilité de recherche" : l'auteur affirme que var rend difficile la recherche d'endroits où MyType est utilisé. C'est vrai. Tout comme les interfaces. En fait, pourquoi voudrais-je savoir où la classe est utilisée ? Je pourrais être plus intéressé par l'endroit où elle est instanciée et cela sera toujours recherchable car quelque part son constructeur doit être invoqué (même si cela est fait indirectement, le nom du type doit être mentionné quelque part).

Answer 3

Var, à mon avis, en C# est une bonne chose tm . Toute variable ainsi typée est toujours fortement typée, mais son type provient du côté droit de l'affectation où elle est définie. Puisque l'information sur le type est disponible sur le côté droit, dans la plupart des cas, il est inutile et trop verbeux d'avoir à l'entrer également sur le côté gauche. Je pense que cela augmente considérablement la lisibilité sans diminuer la sécurité des types.

De mon point de vue, l'utilisation de bonnes conventions de dénomination pour les variables et les méthodes est plus importante du point de vue de la lisibilité que les informations de type explicites. Si j'ai besoin des informations de type, je peux toujours survoler la variable (dans VS) et les obtenir. En général, cependant, l'information explicite sur le type ne devrait pas être nécessaire pour le lecteur. Pour le développeur, dans VS, vous obtenez toujours Intellisense, indépendamment de la façon dont la variable est déclarée. Ceci étant dit, il peut toujours y avoir des cas où il est utile de déclarer explicitement le type - peut-être avez-vous une méthode qui renvoie une variable de type List<T> mais vous voulez le traiter comme un IEnumerable<T> dans votre méthode. Pour s'assurer que vous utilisez l'interface, déclarer la variable du type interface peut rendre cela explicite. Ou, peut-être, vous voulez déclarer une variable sans valeur initiale - parce qu'elle obtient immédiatement une valeur basée sur une certaine condition. Dans ce cas, vous avez besoin du type. Si l'information sur le type est utile ou nécessaire, allez-y et utilisez-la. Je pense cependant qu'elle n'est généralement pas nécessaire et que le code est plus facile à lire sans elle dans la plupart des cas.

Answer 4

Ni l'un ni l'autre n'est absolument vrai ; var peut avoir des effets tant positifs que négatifs sur la lisibilité. A mon avis, var doit être utilisé lorsque l'un des cas suivants est vrai :

1. Le type est anonyme (enfin, vous n'avez pas le choix ici, car il debe être var dans ce cas)
2. Le type est évident sur la base de l'expression affectée (c'est à dire var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating() )

var n'a pas d'impact sur les performances, puisqu'il s'agit d'un sucre syntaxique ; le compilateur déduit le type et le définit une fois qu'il est compilé en IL. en fait dynamique à ce sujet.

Answer 5

Par Eric Lippert, ingénieur principal en conception de logiciels au sein de l'équipe C# :

Pourquoi le var mot-clé introduit ?

T existe aujourd'hui, l'autre qui apparaîtra dans la version 3.0.

La première raison est que cette incroyablement laid à cause de tous les redondance :

Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();

A j'ai écrit pire. Chaque fois que vous êtes forcé de taper exactement la même chose deux fois, c'est supprimer. Beaucoup plus agréable à écrire

var mylists = new Dictionary<string,List<int>>();

et laisser le compilateur déterminer ce que type est basé sur l'affectation.

Deuxièmement, C# 3.0 anonymes. Puisque les types anonymes sont par définition n'ont pas de nom, vous besoin de à être capable de déduire le type de la variable à partir de l'expression d'initialisation si son type est anonyme.

C'est moi qui souligne. L'article complet, C# 3.0 est toujours typée statiquement, honnêtement ! et la suite série sont plutôt bons.

C'est ce que var est pour. Les autres utilisations ne fonctionneront probablement pas aussi bien. Toute comparaison avec JScript, VBScript ou le typage dynamique est totalement absurde. Remarquez encore, var es requis pour que certaines autres fonctionnalités fonctionnent en .NET.