Utilisation du mot-clé var en C#

j'utilise var largement. On a critiqué le fait que cela réduise la lisibilité du code, mais aucun argument ne vient appuyer cette affirmation.

Certes, cela peut signifier qu'il n'est pas clair de quel type il s'agit. Et alors? C'est en fait le point d'une conception découplée. En traitant avec des interfaces, vous êtes emphatiquement pas intéressé par le type une variable A. var va beaucoup plus loin, vrai, mais je pensez que l'argument reste le même du point de vue de la lisibilité: le programmeur ne devrait pas être réellement intéressé par le type de la variable mais plutôt dans ce qu'une variable fait . C'est pourquoi Microsoft appelle aussi type inference "Duck typing."

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

si j'utilise une variable déclarée var et que je me demande pourquoi la variable est là, il y a quelque chose de fondamentalement erroné avec mon code. var n'est pas la cause, il rend seulement les symptômes visibles. Ne blâmez pas le messager.

maintenant, l'équipe C# a publié une ligne directrice 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 d'alternative réelle à var ). Eh bien, c'est fichu. Aussi longtemps que L'équipe C# Ne me donne pas un argument valable pour cette ligne directrice, je vais l'ignorer parce que selon mon opinion professionnelle et personnelle, c'est de la pure foutaise. (Désolé, je n'ai aucun lien avec la ligne directrice en question.)

en Fait, il y a quelques (superficiellement) bonnes explications sur la raison pour laquelle vous ne devriez pas utiliser var mais je crois toujours qu'ils sont largement faux. Prenons l'exemple de "searchabililty": l'auteur affirme que var rend difficile la recherche de lieux où MyType est utilisé. Droit. Les interfaces aussi. En fait, pourquoi voudrais-je savoir où la classe est-elle utilisée? Je pourrais être plus intéressé par où il est instancié et ce sera toujours recherchable parce que quelque part son constructeur doit être invoqué (même si cela est fait indirectement, le nom de type doit être mentionné quelque part).

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

de mon point de vue, l'utilisation de bonnes conventions de nommage pour les variables et les méthodes est plus importante du point de vue de la lisibilité que l'information de type explicite. Si j'ai besoin de l'information de type, je peux toujours survoler la variable (en VS) et l'obtenir. En général, cependant, le lecteur ne devrait pas avoir besoin d'une information de type explicite. Pour le développeur, dans VS vous obtenez toujours Intellisense, indépendamment de la façon dont la variable est déclarée. Ayant dit que, il peut encore avoir des cas où il est logique de déclarer explicitement le type, peut-être que vous avez une méthode qui retourne un List<T> , mais vous voulez le traiter comme un IEnumerable<T> dans votre méthode. Pour vous assurer que vous utilisez l'interface, en déclarant la variable du type d'interface peut explicitement. Ou, peut-être, vous voulez déclarer une variable sans valeur initiale -- parce qu'il obtient immédiatement une valeur basée sur une condition. Dans ce cas, vous avez besoin du type. Si l'information de type est utile ou nécessaire, allez-y et utilisez-le. Je pense, cependant, que typiquement il n'est pas nécessaire et le code est plus facile à lire sans elle 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 devrait être utilisé lorsque l'un ou l'autre des éléments suivants est vrai:

1. le type est anonyme (bien, vous n'avez pas le choix ici, car il doit être var dans ce cas)
2. le type est évident sur la base de l'expression assignée (i.e. var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating() )

var n'a pas d'impact sur les performances, car c'est du sucre syntaxique; le compilateur en déduit le type et le définit une fois qu'il est compilé en IL; il n'y a rien réellement dynamique à ce sujet.

de Eric Lippert, un ingénieur en conception de logiciels Senior de L'équipe C#:

pourquoi le mot-clé var a-t-il été introduit?

Il y a deux raisons, l'une qui il existe aujourd'hui, celle qui va de la récolte jusqu' dans la version 3.0.

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

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

et c'est un simple exemple: – j'ai écrit pour le pire. Chaque fois que vous êtes forcé tapez exactement deux fois la même chose, c'est une redondance que nous pouvons supprimer. Beaucoup plus agréable à écrire

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

et laisser le compilateur le type est fondé sur la cession.

deuxièmement, C # 3.0 introduit anonyme type. Depuis les types anonymes par définition n'ont pas de nom, vous besoin pour être en mesure d'en déduire le type de la variable de l'initialisation expression si son type est anonyme.

c'est moi qui souligne. L'article entier, C# 3.0 est encore statiquement dactylographié, honnête! , et la suite série sont assez bons.

C'est à ça que sert var . D'autres utilisations ne fonctionneront probablement pas aussi bien. Toute comparaison avec JScript, VBScript, ou la dactylographie dynamique est total bunk. Notez encore une fois, var est nécessaire afin d'avoir certaines autres fonctions .NET.

je pense que l'utilisation de var devrait être couplée avec 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 ceci:

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

si elle était plus comme ceci:

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

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

La même chose peut s'appliquer à d'autres situations. C'est assez inutile:

var x = SaveFoo(foo);

... mais cela a du sens:

var saveSucceeded = SaveFoo(foo);

chacun pour soi, je suppose. Je me suis trouvé à faire cela, ce qui est tout simplement insensé:

var f = (float)3;

j'ai besoin d'une sorte de programme var en 12 étapes. Mon nom est Matt, et je (ab)utilisation de la var.

nous avons adopté le code ethos "pour les personnes, pas les machines", basé sur l'hypothèse que vous passez plusieurs fois plus de temps en mode maintenance que sur le nouveau développement.

pour moi, cela exclut l'argument que le compilateur "sait" quel type est la variable-bien sûr, vous ne pouvez pas écrire de code invalide la première fois parce que le compilateur arrête votre code de compiler, mais lorsque le développeur suivant lit le code dans 6 mois, ils doivent être en mesure de déduire ce que la variable fonctionne correctement ou incorrectement et identifie 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 parce qu'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 plus une chose stylistique, qui tend à être subjective. Il peut ajouter des incohérences, quand vous utilisez var et quand vous ne le faites pas.

un autre cas de préoccupation, dans l'appel suivant vous ne pouvez pas dire simplement en regardant le code le type retourné par CallMe :

var variable = CallMe();

c'est ma principale plainte contre var.

j'utilise var quand je déclare les délégués anonymes dans les méthodes, d'une certaine façon 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 de la dernier exemple de code basé sur Julian entrée

Var n'est pas du tout une variante. La variable est encore fortement tapée, c'est juste que vous n'appuyez pas sur les touches pour l'obtenir de cette façon. Vous pouvez le survoler en vol stationnaire dans Visual Studio pour voir le type. Si vous lisez le code imprimé, il est possible que vous ayez besoin de réfléchir un peu pour comprendre ce qu'est le type. Mais il n'y a qu'une seule ligne qui le déclare et beaucoup de lignes qui l'utilisent, donc donner des noms décents aux choses est toujours la meilleure façon de rendre votre code plus facile à suivre.

est utiliser Intellisense paresseux? C'est moins tapé que le nom entier. Ou y a-t-il des choses qui ont moins de travail mais qui ne méritent pas d'être critiquées? Je pense que oui, et var est l'un d'entre eux.

le moment le plus probable où vous aurez besoin de ceci est pour les types anonymes (où il est 100% requis); mais il évite également la répétition pour les cas insignifiants, et IMO rend la ligne plus claire. Je n'ai pas besoin de voir le type deux fois pour une initialisation simple.

par exemple:

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

(merci de ne pas modifier les propriétés hscroll dans l'au-dessus - ça prouve le point!!!)

vs:

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

il y a, cependant, il arrive que cela soit trompeur et que cela puisse causer des bogues. 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ù la var est difficile: les revues de code hors ligne, en particulier celles effectuées sur papier.

Vous ne pouvez pas compter sur les effleurements.

Je ne vois pas où est le problème..

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

vous avez encore plein d'intellisense sur "quelque chose", et pour tout cas ambigu vous avez vos tests unitaires, Non? ( pensez-vous? )

ce n'est pas varchar, ce n'est pas faible, et ce n'est certainement pas dynamique ou faible Dactylographie. Il arrête maddnes comme ceci:

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

et de réduire ce total mindclutter à:

var v = new List<somethinglongtypename>();

Nice, pas tout à fait comme nice:

v = List<somethinglongtypename>();

mais alors c'est à ça que sert Boo .

si quelqu'un utilise le mot-clé var parce qu'il ne veut pas" comprendre le type", c'est certainement la mauvaise raison. Le mot-clé var ne crée pas de variable avec un type dynamique, le compilateur doit encore connaître le type. Comme la variable a toujours un type spécifique, le type doit aussi être évident dans le code si possible.

les bonnes raisons d'utiliser le mot-clé var sont par exemple:

• où c'est nécessaire, c'est à dire à déclarer une référence pour un type anonyme.
• où il rend le code plus lisible, c'est-à-dire en supprimant les déclarations de réputation.

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'avez pas à comprendre le type de données en trouvant d'abord ce que le code fait.

compte tenu de la puissance D'Intellisense est maintenant, je ne suis pas sûr var est plus difficile à lire que d'avoir des variables membres dans une classe, ou des variables locales dans une méthode qui sont définis hors de la zone de l'écran visible.

si vous avez une ligne de code telle que

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

Est beaucoup plus facile ou plus difficile à lire que:

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

je pense que la chose clé avec VAR est de ne l'utiliser que là où c'est approprié, c'est-à-dire quand on fait des choses dans Linq qu'il facilite (et probablement dans d'autres cas).

si vous avez got un type pour quelque chose dans le puis vous devez l'utiliser - ne pas le faire est paresse simple (par opposition à la paresse créative qui est généralement à encourager - bons programmeurs oft travail très difficile d'être paresseux et pourrait être considéré comme la source de la chose dans le premier lieu.)

une interdiction générale est aussi mauvaise qu'un abus de la construction en premier lieu, mais il faut qu'il y ait une norme de codage raisonnable.

l'autre chose à se rappeler est que ce n'est pas un VB type var en ce qu'il ne peut pas changer de types - il est une variable fortement typé son juste que le type est inféré (ce qui est pourquoi il ya des gens qui vont argumenter que son pas déraisonnable de l'utiliser dans, disons, un foreach, mais je ne suis pas d'accord pour les raisons à la fois la lisibilité et la maintenabilité).

je soupçonne celui-ci va courir et courir ( - :

Murph

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

volé dans le post sur cette question à CodingHorror :

malheureusement, vous et les autres vous êtes trompés. Bien que je convienne avec vous que la redondance n'est pas une bonne chose, la meilleure façon de résoudre ce problème aurait été de faire quelque chose comme:

Monobjet m = new();

ou si vous passez des paramètres:

Personne p = new("Prénom", "Nom);

Où, dans la création d'un nouvel objet, le compilateur déduit le type de la gauche et non le droit. Cela présente d'autres avantages par rapport au "var", en ce sens qu'il pourrait être utilisé dans les déclarations sur le terrain (il y a aussi d'autres domaines où il pourrait être utile, mais je n'y reviendrai pas ici).

à la fin, il n'était tout simplement pas destiné à réduire la redondance. Ne m'obtenez pas le faux, " var " est très important en C# pour les types anonymes/projections, mais l'utilisation ici est juste loin (et je le dis depuis très, très longtemps) que vous obscurcissez le type qui est utilisé. Avoir à taper deux fois il est trop souvent, mais le déclarer temps zéro est trop peu.

Nicholas Paldino .NET / C# MVP le 20 juin 2008 08: 00

je suppose que si votre principale préoccupation est d'avoir à taper moins, alors il n'y a aucun argument qui va vous balancer de l'utiliser.

Si vous allez seulement à jamais être la personne qui regarde votre code, alors qui s'en soucie? Autrement, dans un cas comme celui-ci:

var people = Managers.People

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

var fc = Factory.Run();

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

sinon, faites de votre mieux le jugement et la "courtoisie" de programmation envers les autres qui pourraient avoir à travailler sur votre projet.

L'utilisation de var au lieu de type explicite rend les remaniements beaucoup plus faciles (Donc je dois contredire les affiches précédentes qui ont signifié qu'il n'a fait aucune différence ou il était purement"sucre syntaxique").

vous pouvez changer le type de déclaration de vos méthodes sans changer chaque fichier où cette méthode est appelée. Imaginez

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

utilisé comme

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

si vous souhaitez reformuler SomeMethod() pour retournez un IEnumerable<MySecondClass> , vous devrez changer la déclaration de la variable (également à l'intérieur du foreach ) à chaque endroit où vous avez utilisé la méthode.

si vous écrivez

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

à la place, vous n'avez pas à le changer.

@aku: un exemple est les critiques de code. Un autre exemple est celui des scénarios de remaniement.

En Gros, Je ne veux pas aller à la chasse aux caractères avec ma souris. Il pourrait ne pas être disponible.

C'est une question de goût. Toute cette agitation sur le type d'une variable disparaît lorsque vous vous habituez à des langues dactylographiées dynamiquement. C'est-à-dire, si vous commencez jamais à les aimer (Je ne suis pas sûr que tout le monde peut, mais je le fais).

C# var est assez cool en ce qu'il regarde comme le typage dynamique, mais est en réalité statique frappe - le compilateur impose correct utilisation.

le type de votre variable n'est pas vraiment si important (cela a déjà été dit). Il doit ê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 customerList contienne un int ...

j'attends toujours de voir ce que mon patron pense de cette affaire - j'ai une couverture "go ahead" pour utiliser toute nouvelle construction en 3.5, mais que ferons-nous à propos l'entretien?

dans votre comparaison entre IEnumerable<int> et IEnumerable<double> vous n'avez pas à vous inquiéter - si vous passez le mauvais type votre code ne compilera pas de toute façon.

il n'y a pas de problème de sécurité de type, puisque var est et non dynamique. C'est juste de la magie de compilateur et n'importe quel type d'appels dangereux que vous faites se fera attraper.

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
    };

regardez maintenant anonEnumeration dans intellisense et il 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 très intelligent - les types anon 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 avez 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;

ça dépend de votre point de vue. Personnellement, je n'ai jamais eu aucune difficulté à comprendre un morceau de code en raison de var "abus", et mes collègues de travail et je l'utilise beaucoup partout. (Je suis d'accord que l'Intellisense est un énorme aider à cet égard.) Je l'accueille comme un moyen d'éliminer les miettes répétitives.

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

étaient vraiment que impossible à traiter, personne n'utiliserait dynamiquement tapé langues.

j'utilise var seulement quand il est clair de voir quel type est utilisé.

par exemple, j'utiliserais var dans ce cas, parce que 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, parce que vous devez faire glisser la souris sur le code et regarder l'infobulle pour voir quel type retourne MyFunction:

var x = MyClass.MyFunction();

surtout, I jamais utiliser var dans les cas où la droite n'est même pas une méthode, mais seulement une valeur:

var x = 5;

(parce que le compilateur ne peut pas savoir si je veux un octet, court, int ou quoi que ce soit)

pour moi, l'antipathie envers var illustre l'importance du bilinguisme dans .NET. Pour les programmeurs C# qui ont également fait VB.net, les avantages de var sont intuitivement évidents. La norme C# déclaration de:

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

est l'équivalent, en VB. net, de dactylographier ceci:

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

personne ne fait ça sur VB.net. Ce serait idiot, parce que depuis la première version de .NET vous avez été capable de faire cela...

Dim whatever As New List(Of String)

...qui crée la variable et initialise tout dans une ligne raisonnablement compacte. Ah, mais si vous voulez 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 à faire en C#, et évidemment ne pouvait pas utiliser var pour:

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

si vous besoin le type d'être quelque chose différent, il 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 ça qu'il est là. N'importe quoi d'autre est une utilisation trop loin. Comme beaucoup de gens qui ont grandi sur C, je suis habitué à regarder la gauche de la déclaration pour le type. Je ne regarde pas le bon côté à moins d'y être obligé. Utiliser var pour une vieille déclaration me fait faire ça tout le temps, ce que je trouve personnellement inconfortable.

ceux qui disent 'cela n'a pas d'importance, utilisez ce dont vous êtes heureux' ne voient pas l'ensemble du tableau. Chacun prendra le code d'autres personnes à un moment ou à un autre et devra faire face à toutes les décisions qu'ils ont prises au moment où ils l'ont écrit. C'est déjà assez de devoir faire face à des conventions de nommage radicalement différentes, ou - le gripe classique - les styles de soutien, sans ajouter le tout ' var ou pas' chose dans le mélange. Le pire cas sera celui où un programmeur n'a pas utilisé var et puis arrive un responsable qui l'aime, et étend le code en l'utilisant. Donc maintenant tu as un impie désordre.

les Normes sont une bonne chose, précisément parce qu'ils signifient que vous êtes beaucoup plus susceptibles d'être en mesure de ramasser code aléatoire et être en mesure d'analyser rapidement. Plus il y a de choses différentes, plus c'est dur. Et passer au style " var everywhere "fait une grande différence.

Je n'aime pas la dactylographie dynamique, et je n'aime pas la dactylographie implicite - dans les langues qui sont conçues pour eux. J'aime bien Python. Mais C# était conçu comme un langage statiquement explicitement typé et c'est ainsi qu'il devrait rester. Briser les règles pour les types anonymes était assez mauvais; laisser les gens prennent encore plus loin et briser les idiomes de la langue encore plus est quelque chose que je ne suis pas heureux. Maintenant que le génie est sorti de sa bouteille, il n'y retournera jamais. C# deviendra balkanised dans des camps. Pas bonne.

plusieurs fois pendant les tests, je me retrouve à avoir un code comme celui-ci:

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

maintenant, parfois, je vais vouloir voir ce que contient L'autre chose elle-même, quelque autre chose n'est pas le même type que CallMethod() retourne. Depuis que j'utilise var cependant, je viens de changer ceci:

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

à ceci:

var something = myObject.SomeProperty.SomeOtherThing;

Sans var, j'aimerais 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 gagne du temps, il faut moins de touches pour taper:

StringBuilder sb = new StringBuilder();

que

var sb = new StringBuilder();

comptez les si vous ne me croyez pas...

19 contre 21

Je t'expliquerai s'il le faut, mais essaie... (selon l'état actuel de votre intellisense vous devez entrer un couple de plus pour chacun d'entre eux)

et c'est vrai pour tous type vous pouvez penser à!!

mon sentiment personnel est que var ne devrait jamais être utilisé sauf lorsque le type n'est pas connu parce qu'il réduit la readabiltiy de 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 forcer à sérialiser son entrée. Pourquoi quelqu'un voudrait que son cerveau travaille plus dur? C'est ce que sont les ordinateurs.

j'ai divisé var partout, les seuls endroits douteux pour moi sont les types courts internes, par exemple je préfère int i = 3; plutôt que var i = 3;

il peut certainement rendre les choses plus simples, du 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 .

Addendum: Un peu de temps passé avec un langage réel l'inférence de type (par exemple, F#) seront de bons compilateurs sont à obtenir le type des expressions de droite. Il a certainement signifié que j'ai tendance à utiliser var autant que je peux, et en utilisant un type explicite maintenant indique que la variable n'est pas du type d'expression d'initialisation.

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