Utilisation du mot-clé var en C#

https://stackoverflow.com/questions/41479

09-06-2019
|

Question

Après avoir discuté avec des collègues concernant l'utilisation du mot-clé 'var' en C# 3, je me suis demandé quelles étaient les opinions des gens sur les utilisations appropriées de l'inférence de type via var ?

Par exemple, j'ai utilisé paresseusement 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 de var sont les suivantes : -

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

Fait intéressant, LINQ semble être une zone grise, par exemple : -

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

Il est clair quels seront les résultats dans la mesure où ce sera un type qui implémentera IEnumerable, mais ce n'est pas tout à fait évident de la même manière qu'une var déclarant un nouvel objet.

C'est encore pire quand il s'agit de LINQ to objets, 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 ici un réel souci concernant la sécurité des types - par exemple, si nous devions placer les résultats de cette requête dans une méthode surchargée qui acceptait IEnumerable<int> et IEnumerable<double>, l'appelant pourrait par inadvertance transmettre 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 du compilateur peuvent ne pas être émises lorsque vous transmettez involontairement le mauvais type à une méthode.

La solution

je pense toujours var peut rendre le code plus lisible dans certains cas.Si j'ai une classe Customer avec une propriété Orders et que je souhaite l'attribuer à une variable, je ferai simplement ceci :

var orders = cust.Orders;

Je m'en fiche 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 la parcourir ou obtenir son décompte ou quelque chose comme ça 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 client. Commandes en cours (disons de ObservableCollection<Order> à IList<Order>), alors je dois également modifier cette déclaration - quelque chose que je n'aurais pas à faire si j'avais utilisé var en premier lieu.

Autres conseils

j'utilise var largement.Des critiques ont été formulées selon lesquelles cela diminuerait la lisibilité du code, mais aucun argument ne vient étayer cette affirmation.

Certes, cela peut vouloir dire qu’il n’est pas clair à quel type nous avons affaire.Et alors?C’est en fait l’intérêt d’une conception découplée.Lorsqu'il s'agit d'interfaces, vous êtes catégoriquement pas intéressé par le type d’une variable. var va beaucoup plus loin, c'est vrai, mais je pense que l'argument reste le même d'un point de vue lisibilité :Le programmeur ne devrait pas réellement s'intéresser au type de variable mais plutôt à ce qu'est une variable. fait.C'est pourquoi Microsoft appelle également l'inférence de type « typage de canard ».

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

Si j'utilise un var variable déclarée et je ne comprends pas à quoi sert la variable, il y a quelque chose de fondamentalement qui ne va pas avec mon code. var n’en est pas la cause, elle ne fait que rendre visibles les symptômes.Ne blâmez pas le messager.

Maintenant, l'équipe C# a publié une directive de codage indiquant que var devrait seulement être utilisé pour capturer le résultat d'une instruction LINQ qui crée un type anonyme (car ici, nous n'avons pas de véritable alternative à var).Eh bien, merde.Tant que l'équipe C# ne me donne pas d'arguments solides en faveur de cette directive, je vais l'ignorer car, à mon avis professionnel et personnel, c'est de la pure bêtise.(Désolé;Je n'ai aucun lien vers la directive en question.)

En fait, il y en a (superficiellement) bonnes explications pourquoi vous ne devriez pas utiliser var mais je continue de croire qu’ils ont largement tort.Prenons l'exemple de la « capacité de recherche » :l'auteur affirme que var il est difficile de rechercher des endroits où MyType est utilisé.Droite.Les interfaces aussi.En fait, pourquoi voudrais-je savoir où la classe est utilisée ?Je serais peut-être plus intéressé par l'endroit où il est instancié et cela sera toujours consultable car quelque part son constructeur doit être invoqué (même si cela est fait indirectement, le nom du type doit être mentionné quelque part).

Var, à mon avis, en C# est un bonne chose^tm.Toute variable ainsi typée est toujours fortement typée, mais elle obtient son type du côté droit de l'affectation où elle est définie.Étant donné que les informations de type sont disponibles sur le côté droit, dans la plupart des cas, il est inutile et trop détaillé de devoir également les saisir 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 l'obtenir.En règle générale, cependant, les informations de type explicites ne devraient pas être nécessaires au lecteur.Pour le développeur, dans VS, vous obtenez toujours Intellisense, quelle que soit la façon dont la variable est déclarée.Cela dit, il peut encore y avoir des cas où il est judicieux de déclarer explicitement le type - peut-être avez-vous une méthode qui renvoie un List<T>, mais vous voulez le traiter comme un IEnumerable<T> dans votre méthode.Pour vous assurer que vous utilisez l'interface, déclarer la variable du type d'interface peut rendre cela explicite.Ou peut-être souhaitez-vous déclarer une variable sans valeur initiale, car elle obtient immédiatement une valeur basée sur une condition.Dans ce cas, vous avez besoin du type.Si les informations de type sont utiles ou nécessaires, utilisez-les.Je pense cependant que ce n'est généralement pas nécessaire et que le code est plus facile à lire sans cela dans la plupart des cas.

Ni l’un ni l’autre n’est absolument vrai ; var peut avoir des effets à la fois positifs et négatifs sur la lisibilité.À mon avis, var doit être utilisé lorsque l’une des conditions suivantes est vraie :

Le type est anonyme (enfin, vous n'avez pas le choix ici, car il doit être var dans ce cas)
Le type est évident en fonction de l'expression attribuée (c'est-à-dire var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

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

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

Pourquoi le var mot-clé introduit ?

Il y a deux raisons, une qui existe aujourd'hui, une qui apparaîtra en 3.0.

La première raison est que ce code est incroyablement laid à cause de toute la redondance:

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

Et c'est un exemple simple - j'ai écrit pire.Chaque fois que vous êtes obligé de taper exactement la même chose deux fois, c'est une redondance que nous pouvons supprimer.C'est beaucoup plus agréable à écrire

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

et laissez le compilateur déterminer quel est le type basé sur l'affectation.

Deuxièmement, C # 3.0 présente des types anonymes.Puisque les types anonymes par définition n'ont pas de noms, vous besoin Pour pouvoir déduire le type de la variable de l'expression d'initialisation si son type est anonyme.

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

C'est quoi var est pour.D’autres utilisations ne fonctionneront probablement pas aussi bien.Toute comparaison avec JScript, VBScript ou le typage dynamique est une supercherie totale.Notez encore, var est requis afin que certaines autres fonctionnalités fonctionnent dans .NET.

Je pense que l'utilisation de var devrait être associée à des noms de variables judicieusement choisis.

Je n'ai aucun problème à utiliser var dans une instruction foreach, à condition que ce ne soit pas comme ça :

foreach (var c in list) { ... }

Si c'était plutôt ça :

foreach (var customer in list) { ... }

...alors quelqu'un lisant le code serait beaucoup plus susceptible de comprendre ce qu'est une « liste ».Si vous contrôlez le nom de la variable de liste elle-même, c'est encore mieux.

La même chose peut s’appliquer à d’autres situations.C'est plutôt inutile :

var x = SaveFoo(foo);

...mais c'est logique :

var saveSucceeded = SaveFoo(foo);

Chacun son truc, je suppose.Je me suis retrouvé à faire ça, ce qui est tout simplement fou :

var f = (float)3;

J'ai besoin d'une sorte de programme var en 12 étapes.Je m'appelle Matt et j'utilise (ab) var.

Nous avons adopté la philosophie « Code pour les personnes, pas pour les machines », basée sur l'hypothèse que vous passez plusieurs fois plus de temps en mode maintenance qu'en nouveau développement.

Pour moi, cela exclut l'argument selon lequel le compilateur "sait" de quel type est la variable - bien sûr, vous ne pouvez pas écrire de code invalide la première fois car le compilateur arrête la compilation de votre code, mais lorsque le développeur suivant lit le code dans 6 mois, ils doivent être capables de déduire ce que fait la variable correctement ou incorrectement et d'identifier rapidement la cause des problèmes.

Ainsi,

var something = SomeMethod();

est interdit par nos normes de codage, mais ce qui suit est encouragé dans notre équipe car il augmente la lisibilité :

var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
   DoWork( item ); 
}

Ce n'est pas mal, c'est plutôt une question de style, qui a tendance à être subjective.Cela peut ajouter des incohérences, lorsque vous utilisez var et lorsque vous ne le faites pas.

Autre cas de préoccupation, lors de l'appel suivant, vous ne pouvez pas savoir simplement en regardant le code le type renvoyé par CallMe:

var variable = CallMe();

C'est mon principal reproche contre var.

J'utilise var lorsque je déclare des délégués anonymes dans les méthodes, var semble plus propre que si j'utilisais Func.Considérez ce code :

var callback = new Func<IntPtr, bool>(delegate(IntPtr hWnd) {
   ...
});

MODIFIER:Mise à jour du dernier exemple de code en fonction de la saisie de Julian

Le Var n’est pas du tout une variante.La variable est toujours fortement typée, c'est juste que vous n'appuyez pas sur les touches pour l'obtenir ainsi.Vous pouvez le survoler dans Visual Studio pour voir le type.Si vous lisez du code imprimé, il est possible que vous deviez réfléchir un peu pour déterminer quel est son type.Mais il n'y a qu'une seule ligne qui le déclare et de nombreuses lignes qui l'utilisent, donc donner des noms décents aux choses reste le meilleur moyen de rendre votre code plus facile à suivre.

L’utilisation d’Intellisense est-elle paresseuse ?C'est moins typé que le nom entier.Ou y a-t-il des choses qui demandent moins de travail mais qui ne méritent pas de critiques ?Je pense qu'il y en a, et var en fait partie.

Le moment le plus probable où vous en aurez besoin est pour les types anonymes (où c'est requis à 100 %) ;mais cela évite également les répétitions pour les cas triviaux, et l'OMI rend la ligne plus claire.Je n'ai pas besoin de voir le type deux fois pour une simple initialisation.

Par exemple:

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

(s'il vous plaît, ne modifiez pas le hscroll ci-dessus - cela prouve un peu le point !!!)

contre:

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

Il arrive cependant que cela soit trompeur et puisse potentiellement provoquer des bugs.Soyez prudent en utilisant var si la variable d'origine et le type initialisé n'étaient pas identiques.Par exemple:

static void DoSomething(IFoo foo) {Console.WriteLine("working happily") }
static void DoSomething(Foo foo) {Console.WriteLine("formatting hard disk...");}

// this working code...
IFoo oldCode = new Foo();
DoSomething(oldCode);
// ...is **very** different to this code
var newCode = new Foo();
DoSomething(newCode);

Un cas précis où var est difficile :révisions de code hors ligne, en particulier celles effectuées sur papier.

Vous ne pouvez pas compter sur les survols de la souris pour cela.

Je ne vois pas quel est le problème..

var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!

Vous disposez toujours d'une intelligence complète sur « quelque chose », et pour tout cas ambigu, vous avez vos tests unitaires, n'est-ce pas ?( est-ce que tu?)

Ce n'est pas du varchar, ce n'est pas dim, et ce n'est certainement pas un typage dynamique ou faible.Cela arrête les folies comme ceci :

List<somethinglongtypename> v = new List<somethinglongtypename>();

et réduire ce désordre mental total à :

var v = new List<somethinglongtypename>();

Sympa, pas aussi sympa que :

v = List<somethinglongtypename>();

Mais alors c'est quoi Huer est pour.

Si quelqu'un utilise le var mot-clé parce qu'ils ne veulent pas "comprendre le type", ce n'est certainement pas la bonne raison.Le var Le mot-clé ne crée pas de variable avec un type dynamique, le compilateur doit toujours connaître le type.Comme la variable a toujours un type spécifique, le type doit également être évident dans le code si possible.

De bonnes raisons d'utiliser le var les mots-clés sont par exemple :

Là où c'est nécessaire, c'est-à-direpour déclarer une référence pour un type anonyme.
Où cela rend le code plus lisible, c'est-à-diresupprimer les déclarations répétitives.

L'écriture du type de données rend souvent le code plus facile à suivre.Il montre les types de données que vous utilisez, de sorte que vous n'ayez pas à déterminer le type de données en déterminant d'abord ce que fait le code.

Compte tenu de la puissance actuelle d'Intellisense, je ne suis pas sûr que var soit plus difficile à lire que d'avoir des variables membres dans une classe ou des variables locales dans une méthode définies hors de la zone visible de l'écran.

Si vous avez une ligne de code telle que

IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

C'est beaucoup plus facile ou plus difficile à lire que :

var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

Je pense que l'essentiel avec VAR est de ne l'utiliser que lorsque cela est approprié, c'est-à-direlorsque vous faites des choses dans Linq, cela facilite (et probablement dans d'autres cas).

Si vous avez a obtenu un type pour quelque chose dans le alors vous devriez l'utiliser - ne pas le faire est une simple paresse (par opposition à la paresse créative qui doit généralement être encouragée - les bons programmeurs travaillent souvent très dur pour être paresseux et pourraient être considérés comme la source de la chose en premier lieu).

Une interdiction générale est aussi grave que d'abuser de la construction en premier lieu, mais il doit y avoir une norme de codage sensée.

L'autre chose à retenir est que ce n'est pas une variable de type VB dans la mesure où elle ne peut pas changer de type - elle est une variable fortement typée, c'est juste que le type est déduit (c'est pourquoi certaines personnes diront qu'il n'est pas déraisonnable de l'utiliser, disons, dans un foreach, mais je ne serais pas d'accord pour des raisons de lisibilité et de maintenabilité).

Je soupçonne que celui-ci va fonctionner encore et encore (- :

Murph

Bien sûr, int est facile, mais lorsque le type de la variable est IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var rend les choses beaucoup plus faciles.

Volé au poster sur ce problème sur CodingHorror:

Malheureusement, vous et tout le monde vous êtes à peu près trompés.Même si je suis d'accord avec vous sur le fait que la redondance n'est pas une bonne chose, la meilleure façon de résoudre ce problème aurait été de procéder comme suit :

MonObjet m = new();

Ou si vous passez des paramètres :

Personne p = new("FirstName", "LastName);

Où lors de la création d’un nouvel objet, le compilateur déduit le type du côté gauche, et non du côté droit.Cela présente d'autres avantages par rapport à "var", dans le sens où il pourrait également être utilisé dans les déclarations de champs (il existe également d'autres domaines dans lesquels cela pourrait également être utile, mais je n'entrerai pas dans les détails ici).

En fin de compte, l’objectif n’était tout simplement pas de réduire la redondance.Ne vous méprenez pas, "var" est TRÈS important en C# pour les types/projections anonymes, mais son utilisation ici est tout simplement BEAUCOUP (et je le dis depuis très, très longtemps) car vous masquez le type qui est en train d'être utilisé.Devoir le saisir deux fois est trop fréquent, mais le déclarer zéro fois est trop peu.

Nicholas Paldino MVP .NET/C# le 20 juin 2008 à 08h00

Je suppose que si votre principale préoccupation est de devoir taper moins, alors aucun argument ne vous empêchera de l'utiliser.

Si tu veux seulement jamais soyez la personne qui regarde votre code, alors peu importe ?Sinon, dans un cas comme celui-ci :

var people = Managers.People

c'est bien, mais dans un cas comme celui-ci :

var fc = Factory.Run();

cela court-circuite toutes les déductions de type immédiat que mon cerveau pourrait commencer à former à partir de « l'anglais » du code.

Sinon, utilisez simplement votre meilleur jugement et votre « courtoisie » de programmation envers les autres personnes susceptibles de devoir travailler sur votre projet.

En utilisant var au lieu d'un type explicite, les refactorisations sont beaucoup plus faciles (je dois donc contredire les affiches précédentes qui disaient que cela ne faisait aucune différence ou que c'était purement du "sucre syntaxique").

Vous pouvez modifier le type de retour de vos méthodes sans modifier chaque fichier dans lequel cette méthode est appelée.Imaginer

...
List<MyClass> SomeMethod() { ... }
...

qui est utilisé comme

...
IList<MyClass> list = obj.SomeMethod();
foreach (MyClass c in list)
  System.Console.WriteLine(c.ToString());
...

Si vous vouliez refactoriser SomeMethod() rendre un IEnumerable<MySecondClass>, vous devrez modifier la déclaration de la variable (également à l'intérieur du foreach) partout où vous avez utilisé la méthode.

Si tu écris

...
var list = obj.SomeMethod();
foreach (var element in list)
  System.Console.WriteLine(element.ToString());
...

au lieu de cela, vous n'êtes pas obligé de le changer.

@aku :Un exemple est celui des révisions de code.Un autre exemple est la refactorisation des scénarios.

Fondamentalement, je ne veux pas partir à la recherche de caractères avec ma souris.Il se peut qu'il ne soit pas disponible.

C'est une question de goût.Toute cette agitation à propos du taper d'une variable disparaît lorsque vous vous habituez aux langages typés dynamiquement.C'est, si on commence à les aimer (je ne sais pas si tout le monde peut le faire, mais moi si).

C# var c'est plutôt cool dans le sens où regards comme la saisie dynamique, mais c'est en fait statique typing - le compilateur impose une utilisation correcte.

Le type de votre variable n’est pas vraiment important (cela a déjà été dit).Cela devrait être relativement clair d'après le contexte (ses interactions avec d'autres variables et méthodes) et son nom - ne vous attendez pas à ce que liste de clients contenir un int...

J'attends toujours de voir ce que mon patron pense de cette question - j'ai reçu une autorisation générale pour utiliser toute nouvelle construction dans la version 3.5, mais que ferons-nous à propos de la maintenance ?

Dans votre comparaison entre IEnumerable<int> et IEnumerable<double> vous n'avez pas à vous inquiéter - si vous transmettez le mauvais type, votre code ne sera pas compilé de toute façon.

Il n'y a aucune préoccupation concernant la sécurité des types, car var est pas dynamique.C'est juste de la magie du compilateur et tout type d'appel dangereux que vous effectuez sera intercepté.

Var est absolument nécessaire pour Linq :

var anonEnumeration =
    from post in AllPosts()
    where post.Date > oldDate
    let author = GetAuthor( post.AuthorId )
    select new { 
        PostName = post.Name, 
        post.Date, 
        AuthorName = author.Name
    };

Maintenant regarde anonÉnumération dans IntelliSense et cela apparaîtra quelque chose comme IEnumerable<'a>

foreach( var item in anonEnumeration ) 
{
    //VS knows the type
    item.PostName; //you'll get intellisense here

    //you still have type safety
    item.ItemId;   //will throw a compiler exception
}

Le compilateur C# est assez intelligent : les types anonymes générés séparément auront le même type généré si leurs propriétés correspondent.

En dehors de cela, tant que vous disposez d'IntelliSense, il est logique d'utiliser var partout où le contexte est clair.

//less typing, this is good
var myList = new List<UnreasonablyLongClassName>();

//also good - I can't be mistaken on type
var anotherList = GetAllOfSomeItem();

//but not here - probably best to leave single value types declared
var decimalNum = 123.456m;

Je suppose que cela dépend de votre point de vue.Personnellement, je n'ai jamais eu de difficulté à comprendre un morceau de code à cause de var "abus", et mes collègues et moi l'utilisons beaucoup partout.(Je suis d'accord qu'Intellisense est d'une aide considérable à cet égard.) Je l'accueille comme un moyen de supprimer les éléments répétitifs.

Après tout, si des déclarations comme

var index = 5; // this is supposed to be bad

var firstEligibleObject = FetchSomething(); // oh no what type is it
                                            // i am going to die if i don't know

si c'était vraiment impossible à gérer, personne n'utiliserait des langages typés dynamiquement.

Je n'utilise var que lorsqu'il est clair de voir quel type est utilisé.

Par exemple, j'utiliserais var dans ce cas, car vous pouvez voir immédiatement que x sera du type "MyClass":

var x = new MyClass();

Je n'utiliserais PAS var dans des cas comme celui-ci, car vous devez faire glisser la souris sur le code et regarder l'info-bulle pour voir quel type MyFunction renvoie :

var x = MyClass.MyFunction();

Surtout, je jamais utilisez var dans les cas où le côté droit n'est même pas une méthode, mais seulement une valeur :

var x = 5;

(car le compilateur ne peut pas savoir si je veux un octet, un short, un int ou autre)

Pour moi, l'antipathie envers var illustre pourquoi le bilinguisme dans .NET est important.Pour les programmeurs C# qui ont également réalisé VB .NET, les avantages de var sont intuitivement évidents.La déclaration C# standard de :

List<string> whatever = new List<string>();

est l'équivalent, en VB .NET, de taper ceci :

Dim whatever As List(Of String) = New List(Of String)

Cependant, personne ne fait cela dans VB .NET.Ce serait idiot, car depuis la première version de .NET, vous pouvez faire cela...

Dim whatever As New List(Of String)

... qui crée la variable et initialise le tout en une seule ligne raisonnablement compacte.Ah, mais et si tu veux un IList<string>, pas un List<string>?Eh bien, dans VB .NET, cela signifie que vous devez faire ceci :

Dim whatever As IList(Of String) = New List(Of String)

Tout comme vous auriez dû le faire en C#, et vous ne pouviez évidemment pas l'utiliser var pour:

IList<string> whatever = new List<string>();

Si tu besoin le type doit être quelque chose de différent, ça peut être.Mais l’un des principes de base d’une bonne programmation est de réduire la redondance, et c’est exactement ce que fait var.

Utilisez-le pour les types anonymes – c’est pour cela qu’il est là.Tout le reste est une utilisation excessive.Comme beaucoup de gens qui ont grandi avec C, j'ai l'habitude de regarder le type à gauche de la déclaration.Je ne regarde pas du côté droit sauf si j'y suis obligé.En utilisant var car toute vieille déclaration m’oblige à faire cela tout le temps, ce que je trouve personnellement inconfortable.

Ceux qui disent « cela n’a pas d’importance, utilisez ce qui vous convient » n’ont pas une vision d’ensemble.Tout le monde reprendra le code des autres à un moment ou à un autre et devra faire face aux décisions qu'il a prises au moment où il l'a écrit.C'est déjà assez pénible de devoir composer avec des conventions de dénomination radicalement différentes, ou - le reproche classique - des styles de renfort, sans ajouter le tout 'var ou pas' dans le mix.Le pire des cas serait celui où un programmeur n'a pas utilisé var puis arrive un responsable qui l'aime et étend le code en l'utilisant.Alors maintenant, vous avez un désordre impie.

Les normes sont une bonne chose précisément parce qu'elles signifient que vous avez d'autant plus de chances de pouvoir récupérer du code aléatoire et de le comprendre rapidement.Plus il y a de choses différentes, plus cela devient difficile.Et passer au style « var partout » crée un grand différence.

Cela ne me dérange pas la saisie dynamique, ni la saisie implicite - dans des langages conçus pour eux.J'aime bien Python.Mais C# a été conçu comme un langage typé de manière statique et explicite et c'est ainsi qu'il devrait rester.Enfreindre les règles pour les types anonymes était déjà assez grave ;laisser les gens aller encore plus loin et briser encore plus les idiomes de la langue est quelque chose qui ne me plaît pas.Maintenant que le génie est sorti de la bouteille, il n’y rentrera plus jamais.C# sera balkanisé en camps.Pas bon.

Plusieurs fois pendant les tests, je me retrouve avec un code comme celui-ci :

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
Console.WriteLine(something);

Maintenant, parfois, je veux voir ce que contient SomeOtherThing lui-même, SomeOtherThing n'est pas du même type que celui renvoyé par CallMethod().Puisque j'utilise var, je change simplement ceci :

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();

pour ça:

var something = myObject.SomeProperty.SomeOtherThing;

Sans var, je devrais également continuer à changer le type déclaré sur le côté gauche.Je sais que c'est mineur, mais c'est extrêmement pratique.

Pour les afficionados qui pensent var permet de gagner du temps, il faut moins de frappes pour taper :

StringBuilder sb = new StringBuilder();

que

var sb = new StringBuilder();

Comptez-les si vous ne me croyez pas...

19 contre 21

Je vous expliquerai s'il le faut, mais essayez-le...(en fonction de l'état actuel de votre intellisense, vous devrez peut-être en saisir quelques autres pour chacun)

Et c'est vrai pour tous les types auxquels vous pouvez penser !!

Mon sentiment personnel est que var ne devrait jamais être utilisé sauf lorsque le type n'est pas connu car cela réduit la lisibilité de la reconnaissance dans le code.Il faut plus de temps au cerveau pour reconnaître le type qu’une ligne complète.Les anciens qui comprennent le code machine et les bits savent exactement de quoi je parle.Le cerveau traite en parallèle et lorsque vous utilisez var, vous le forcez à sérialiser son entrée.Pourquoi voudrait-on faire travailler son cerveau plus fort ?C'est à cela que servent les ordinateurs.

J'ai divisé var partout, les seuls endroits douteux pour moi sont les types courts internes, par ex.je préfère int i = 3; sur var i = 3;

Cela peut certainement rendre les choses plus simples, d'après le code que j'ai écrit hier :

var content  = new Queue<Pair<Regex, Func<string, bool>>>();
...
foreach (var entry in content) { ... }

Cela aurait été extrêmement verbeux sans var.

Addenda:Un peu de temps passé avec une langue avec réel inférence de type (par ex.F#) montrera à quel point les compilateurs sont efficaces pour trouver le bon type d'expressions.Cela signifie certainement que j'ai tendance à utiliser var autant que je peux, et l'utilisation d'un type explicite indique maintenant que la variable n'est pas du type de l'expression d'initialisation.

Aucun, sauf que vous n'avez pas besoin d'écrire deux fois le nom du type. http://msdn.microsoft.com/en-us/library/bb383973.aspx

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow