Uso da palavra-chave var em C #

Após uma discussão com os colegas sobre o uso da palavra-chave 'var' no C # 3, perguntei-me qual seria a opinião das pessoas sobre os usos apropriados da inferência de tipo via var?

Por exemplo, usei preguiçosamente var em circunstâncias questionáveis, por exemplo: -

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.

Os usos mais legítimos de var são os seguintes: -

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

Curiosamente, o LINQ parece ser um pouco de uma área cinzenta, por exemplo: -

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

Está claro quais serão os resultados, pois será um tipo que implementa IEnumerable, no entanto, não é totalmente óbvio da mesma maneira que um var que declara um novo objeto.

É ainda pior quando se trata de LINQ para objetos, por exemplo: -

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

Isso não é melhor que o equivalente foreach (var item em someList) {// ...}.

Há uma preocupação real com a segurança do tipo aqui - por exemplo, se colocarmos os resultados dessa consulta em um método sobrecarregado que aceite IEnumerable <int> e IEnumerable <double>, o chamador poderá inadvertidamente passar para o tipo errado.

var não manter a tipagem forte, mas a questão é realmente se é perigoso para o tipo de não ser imediatamente aparente na definição, algo que é ampliada quando sobrecargas erros do compilador médios não pode ser emitido quando você involuntariamente passar o tipo errado para um método.

Eu ainda acho que varpode tornar o código mais legível em alguns casos. Se eu tiver uma classe Customer com uma propriedade Orders e desejar atribuí-la a uma variável, farei isso:

var orders = cust.Orders;

Eu não me importo se Customer.Orders é IEnumerable<Order>, ObservableCollection<Order>ou BindingList<Order>- tudo o que eu quero é manter essa lista na memória para iterá-la ou obter sua contagem ou algo mais tarde.

Compare a declaração acima com:

ObservableCollection<Order> orders = cust.Orders;

Para mim, o nome do tipo é apenas ruído. E se eu voltar e decidir mudar o tipo de Customer.Orders abaixo da faixa (digamos de ObservableCollection<Order>para IList<Order>), também preciso alterar essa declaração - algo que não precisaria fazer se tivesse usado var no primeiro Lugar, colocar.

Eu uso varextensivamente. Houve críticas de que isso diminui a legibilidade do código, mas nenhum argumento para apoiar essa afirmação.

É certo que pode significar que não está claro com que tipo estamos lidando. E daí? Este é realmente o ponto de um design dissociado. Ao lidar com interfaces, você enfaticamente não está interessado no tipo de variável. varisso leva muito mais longe, é verdade, mas acho que o argumento permanece o mesmo do ponto de vista da legibilidade: o programador não deveria estar realmente interessado no tipo da variável, mas no que uma variável faz . É por isso que a Microsoft também chama a inferência de tipo de "digitação de pato".

Então, o que uma variável faz quando a declaro usando var? Fácil, ele faz o que o IntelliSense me diz que faz. Qualquer raciocínio sobre C # que ignora o IDE fica aquém da realidade. Na prática, todo código C # é programado em um IDE que suporta o IntelliSense.

Se eu estiver usando uma varvariável declarada e ficar confuso para o que a variável existe, existe algo fundamentalmente errado no meu código. varnão é a causa, apenas torna os sintomas visíveis. Não culpe o mensageiro.

Agora, a equipe do C # lançou uma diretriz de codificação afirmando que sóvar deve ser usada para capturar o resultado de uma instrução LINQ que cria um tipo anônimo (porque aqui, não temos uma alternativa real ). Bem, que se dane. Enquanto a equipe de C # não me der um argumento sólido para essa diretriz, vou ignorá-la porque, na minha opinião profissional e pessoal, é pura bobagem. (Desculpe, não tenho nenhum link para a diretriz em questão.)var

Na verdade, existem algumas (superficialmente) boas explicações sobre por que você não deve usar, varmas ainda acredito que elas estão amplamente erradas. Tomemos o exemplo de “capacidade de busca”: o autor alega que vardificulta a busca por locais onde MyTypeé usada. Direita. O mesmo acontece com as interfaces. Na verdade, por que eu gostaria de saber onde a classe é usada? Talvez eu esteja mais interessado em onde é instanciado e isso ainda poderá ser pesquisado porque em algum lugar seu construtor precisa ser chamado (mesmo que isso seja feito indiretamente, o nome do tipo deve ser mencionado em algum lugar).

Var, na minha opinião, em C # é uma coisa boa ^tm . Qualquer variável assim digitada ainda é fortemente digitada, mas ela obtém seu tipo do lado direito da atribuição em que está definida. Como as informações de tipo estão disponíveis no lado direito, na maioria dos casos, é desnecessário e excessivamente detalhado também ter que digitá-las no lado esquerdo. Eu acho que isso aumenta significativamente a legibilidade sem diminuir a segurança do tipo.

Na minha perspectiva, o uso de boas convenções de nomenclatura para variáveis ​​e métodos é mais importante do ponto de vista da legibilidade do que informações explícitas do tipo. Se eu precisar das informações de tipo, sempre posso passar o mouse sobre a variável (no VS) e obtê-la. Geralmente, porém, informações explícitas do tipo não devem ser necessárias para o leitor. Para o desenvolvedor, no VS, você ainda obtém o Intellisense, independentemente de como a variável é declarada. Dito tudo isso, ainda pode haver casos em que faz sentido declarar explicitamente o tipo - talvez você tenha um método que retorne a List<T>, mas queira tratá-lo como umIEnumerable<T>no seu método. Para garantir que você esteja usando a interface, declarar a variável do tipo de interface pode tornar isso explícito. Ou, talvez, você queira declarar uma variável sem um valor inicial - porque ela obtém imediatamente um valor com base em alguma condição. Nesse caso, você precisa do tipo. Se as informações de tipo forem úteis ou necessárias, vá em frente e use-as. Porém, sinto que normalmente não é necessário e o código é mais fácil de ler sem ele na maioria dos casos.

Nenhuma delas é absolutamente verdadeira; varpode ter efeitos positivos e negativos na legibilidade. Na minha opinião, vardeve ser usado quando uma das seguintes situações for verdadeira:

1. O tipo é anônimo (bem, você não tem escolha aqui, pois deve ser var neste caso)
2. O tipo é óbvio com base na expressão atribuída (ie var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

varnão tem impacto no desempenho, pois é açúcar sintático; o compilador infere o tipo e o define quando compilado em IL; não há nada realmente dinâmico nisso.

De Eric Lippert, engenheiro sênior de design de software da equipe de C #:

Por que a varpalavra - chave foi introduzida?

Existem duas razões, uma que existe hoje, uma que aparecerá na versão 3.0.

A primeira razão é que esse código é incrivelmente feio por causa de toda a redundância:

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

E esse é um exemplo simples - escrevi pior. Sempre que você é forçado a digitar exatamente a mesma coisa duas vezes, é uma redundância que podemos remover. Muito melhor escrever

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

e deixe o compilador descobrir qual é o tipo com base na atribuição.

Segundo, o C # 3.0 apresenta tipos anônimos. Como os tipos anônimos, por definição, não têm nomes, é necessário deduzir o tipo da variável a partir da expressão inicial, se o tipo for anônimo.

Ênfase minha. O artigo inteiro, C # 3.0, ainda é estaticamente digitado, honesto! e as séries seguintes são muito boas.

É para isso que varserve. Outros usos provavelmente não funcionarão tão bem. Qualquer comparação com JScript, VBScript ou digitação dinâmica é total. Observe novamente, varé necessário para que outros recursos funcionem no .NET.

Eu acho que o uso de var deve ser associado a nomes de variáveis ​​escolhidos com sabedoria.

Não tenho nenhum problema em usar var em uma instrução foreach, desde que não seja assim:

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

Se fosse mais assim:

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

... então alguém lendo o código teria muito mais chances de entender o que é "lista". Se você tem controle sobre o nome da variável da lista, é ainda melhor.

O mesmo pode se aplicar a outras situações. Isso é bastante inútil:

var x = SaveFoo(foo);

... mas isso faz sentido:

var saveSucceeded = SaveFoo(foo);

Cada um na sua, eu acho. Eu me vi fazendo isso, o que é insano:

var f = (float)3;

Preciso de algum tipo de programa var de 12 etapas. Meu nome é Matt e eu (ab) uso var.

Adotamos o código de ética "Código para pessoas, não para máquinas", com base no pressuposto de que você passa várias vezes mais tempo no modo de manutenção do que no novo desenvolvimento.

Para mim, isso exclui o argumento de que o compilador "sabe" que tipo é a variável - com certeza, você não pode escrever um código inválido pela primeira vez porque o compilador interrompe a compilação do código, mas quando o próximo desenvolvedor estiver lendo o código dentro de seis meses, eles precisam deduzir o que a variável está fazendo de maneira correta ou incorreta e identificar rapidamente a causa dos problemas.

Portanto,

var something = SomeMethod();

é proibido pelos nossos padrões de codificação, mas o seguinte é incentivado em nossa equipe porque aumenta a legibilidade:

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

Não é ruim, é mais uma coisa estilística, que tende a ser subjetiva. Pode adicionar inconsistências, quando você usa var e quando não.

Outro caso de preocupação, na chamada a seguir, você não pode dizer apenas olhando para o código do tipo retornado por CallMe:

var variable = CallMe();

Essa é a minha principal reclamação contra var.

Uso var quando declaro delegados anônimos nos métodos, de alguma forma var parece mais limpo do que se eu usasse Func. Considere este código:

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

EDIT : Atualizado o último exemplo de código com base na entrada de Julian

Var não é como uma variante. A variável ainda é fortemente digitada, mas você não pressiona as teclas para obtê-la dessa maneira. Você pode passar o mouse sobre ele no Visual Studio para ver o tipo. Se você estiver lendo um código impresso, é possível que pense um pouco para descobrir qual é o tipo. Mas há apenas uma linha que a declara e muitas linhas que a utilizam, portanto, dar nomes decentes às coisas ainda é a melhor maneira de facilitar o seu código.

O uso do Intellisense é preguiçoso? É menos digitado que o nome inteiro. Ou há coisas que são menos trabalhosas, mas não merecem críticas? Eu acho que existem, e var é um deles.

O momento mais provável em que você precisará disso é para tipos anônimos (onde é 100% necessário); mas também evita repetições nos casos triviais, e a IMO torna a linha mais clara. Não preciso ver o tipo duas vezes para uma inicialização simples.

Por exemplo:

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

(por favor, não edite o hscroll acima - isso meio que prova o ponto !!!)

vs:

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

No entanto, há ocasiões em que isso é enganoso e pode causar bugs. Tenha cuidado ao usar varse a variável original e o tipo inicializado não forem idênticos. Por exemplo:

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

Um caso específico em que var é difícil: revisões de código offline, especialmente as feitas no papel.

Você não pode confiar em passar o mouse para isso.

Não vejo qual é o grande problema ..

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

Você ainda tem total conhecimento de algo e, para qualquer caso ambíguo, você tem seus testes de unidade, certo? ( você? )

Não é varchar, não é sombrio e certamente não é uma digitação dinâmica ou fraca. Está parando maddnes assim:

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

e reduzindo a desordem total para:

var v = new List<somethinglongtypename>();

Bom, não tão bom quanto:

v = List<somethinglongtypename>();

Mas então é para isso que serve o Boo .

Se alguém está usando a varpalavra - chave porque não deseja "descobrir o tipo", esse é definitivamente o motivo errado. A varpalavra-chave não cria uma variável com um tipo dinâmico, o compilador ainda precisa saber o tipo. Como a variável sempre tem um tipo específico, o tipo também deve ser evidente no código, se possível.

Boas razões para usar a varpalavra - chave são, por exemplo:

• Onde é necessário, ou seja, declarar uma referência para um tipo anônimo.
• Onde torna o código mais legível, ou seja, removendo declarações repetitivas.

Escrever o tipo de dados geralmente torna o código mais fácil de seguir. Ele mostra quais tipos de dados você está usando, para que você não precise descobrir o tipo de dados, primeiro descobrindo o que o código faz.

Dado o quão poderoso o Intellisense é agora, não tenho certeza de que var seja mais difícil de ler do que ter variáveis-membro em uma classe ou variáveis ​​locais em um método definido na área visível da tela.

Se você tiver uma linha de código como

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

É muito mais fácil ou difícil de ler do que:

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

Eu acho que o principal com o VAR é usá-lo apenas quando apropriado, ou seja, ao fazer coisas no Linq que ele facilita (e provavelmente em outros casos).

Se você tem um tipo para algo, deve usá-lo - não fazer isso é preguiça simples (em oposição à preguiça criativa, que geralmente deve ser incentivada) - bons programadores costumam trabalhar muito duro para serem preguiçosos e podem ser considerados a fonte da coisa em primeiro lugar).

Uma proibição geral é tão ruim quanto abusar da construção em primeiro lugar, mas é necessário que haja um padrão de codificação sensato.

A outra coisa a lembrar é que não é um tipo de VB var, pois não pode alterar tipos - é uma variável fortemente tipada, apenas que o tipo é inferido (e é por isso que existem pessoas que argumentam que não é razoável use-o, digamos, em um foreach, mas eu discordaria por razões de legibilidade e manutenção).

Eu suspeito que este vai rodar e rodar (-:

Murph

Claro, inté fácil, mas quando o tipo da variável é IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var torna as coisas muito mais fáceis.

Roubado do post sobre esta questão no CodingHorror :

Infelizmente, você e todos os demais entenderam errado. Embora eu concorde com você que a redundância não é uma coisa boa, a melhor maneira de resolver esse problema seria fazer algo como o seguinte:

Nicholas Paldino .NET / C # MVP em 20 de junho de 2008 08:00

Eu acho que se sua principal preocupação é digitar menos - então não há nenhum argumento que o impeça de usá-lo.

Se você está indo só para nunca ser a pessoa que olha para o seu código, então quem se importa? Caso contrário, em um caso como este:

var people = Managers.People

está tudo bem, mas em um caso como este:

var fc = Factory.Run();

provoca um curto-circuito em qualquer dedução imediata de tipo que meu cérebro possa começar a formar a partir do 'inglês' do código.

Caso contrário, use seu melhor julgamento e programação 'cortesia' para com outras pessoas que possam ter que trabalhar em seu projeto.

O uso em varvez do tipo explícito facilita muito as refatorações (portanto, devo contradizer os pôsteres anteriores que queriam dizer que não faziam diferença ou que era puramente "açúcar sintático").

Você pode alterar o tipo de retorno dos seus métodos sem alterar todos os arquivos nos quais esse método é chamado. Imagine

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

que é usado como

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

Se você quisesse refatorar SomeMethod()para retornar um IEnumerable<MySecondClass>, seria necessário alterar a declaração da variável (também dentro do foreach) em todos os lugares em que você usou o método.

Se você escrever

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

em vez disso, você não precisa alterá-lo.

@aku: Um exemplo são as revisões de código. Outro exemplo são os cenários de refatoração.

Basicamente, não quero caçar tipos com o mouse. Pode não estar disponível.

É uma questão de gosto. Todo esse barulho sobre o tipo de uma variável desaparece quando você se acostuma a linguagens digitadas dinamicamente. Ou seja, se você começar a gostar deles (não tenho certeza se todos podem, mas eu gosto).

C # varé muito legal, pois parece uma digitação dinâmica, mas na verdade é estática - o compilador aplica o uso correto.

O tipo da sua variável não é realmente tão importante (isso já foi dito antes). Deve ser relativamente claro a partir do contexto (suas interações com outras variáveis ​​e métodos) e seu nome - não espere que customerList contenha um int...

Ainda estou esperando para ver o que meu chefe pensa sobre esse assunto - recebi um cobertor "vá em frente" para usar novas construções na versão 3.5, mas o que faremos com a manutenção?

Na sua comparação entre IEnumerable<int>e IEnumerable<double>você não precisa se preocupar - se você passar o tipo errado, seu código não será compilado de qualquer maneira.

Não há preocupação com a segurança de tipo, pois ela nãovar é dinâmica. É apenas mágica do compilador e qualquer tipo de chamada não segura que você fizer será capturado.

Var é absolutamente necessário para o 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
    };

Agora olhe para anonEnumeration no intellisense e parecerá algo comoIEnumerable<'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
}

O compilador C # é bastante inteligente - os tipos gerados separadamente terão o mesmo tipo gerado se suas propriedades corresponderem.

Fora isso, desde que você tenha inteligência, faz sentido usar em varqualquer lugar em que o contexto seja claro.

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

Eu acho que depende da sua perspectiva. Pessoalmente, nunca tive dificuldade em entender um pedaço de código por causa de var"uso indevido", e meus colegas e eu o usamos bastante por todo o lado. (Concordo que o Intellisense é uma grande ajuda nesse sentido.) Congratulo-me com isso como uma maneira de remover detritos repetitivos.

Afinal, se declarações como

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

eram realmente impossíveis de lidar, ninguém usaria linguagens dinamicamente tipadas.

Eu só uso var quando está claro para ver que tipo é usado.

Por exemplo, eu usaria var neste caso, porque você pode ver imediatamente que x será do tipo "MyClass":

var x = new MyClass();

Eu NÃO usaria var em casos como este, porque você precisa arrastar o mouse sobre o código e olhar a dica de ferramenta para ver qual tipo MyFunction retorna:

var x = MyClass.MyFunction();

Especialmente, nunca uso var nos casos em que o lado direito nem sequer é um método, mas apenas um valor:

var x = 5;

(porque o compilador não pode saber se eu quero um byte, curto, int ou o que for)

Para mim, a antipatia para varilustra por que o bilinguismo no .NET é importante. Para os programadores de C # que também fizeram o VB .NET, as vantagens de varsão intuitivamente óbvias. A declaração C # padrão de:

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

é o equivalente, no VB .NET, de digitar isso:

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

Ninguém faz isso no VB .NET, no entanto. Seria bobagem, porque desde a primeira versão do .NET você foi capaz de fazer isso ...

Dim whatever As New List(Of String)

... que cria a variável e inicializa tudo em uma linha razoavelmente compacta. Ah, mas e se você quiser um IList<string>, não um List<string>? Bem, no VB .NET, isso significa que você precisa fazer isso:

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

Assim como você faria em C #, e obviamente não poderia usar varpara:

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

Se você precisar que o tipo seja algo diferente, pode ser. Mas um dos princípios básicos de uma boa programação é reduzir a redundância, e é exatamente isso que o var faz.

Use-o para tipos anônimos - é para isso que serve. Qualquer outra coisa é um uso longe demais. Como muitas pessoas que cresceram em C, estou acostumado a olhar para o lado esquerdo da declaração para o tipo. Não olho para o lado direito, a menos que precise. Usar varqualquer declaração antiga me faz fazer isso o tempo todo, o que eu pessoalmente acho desconfortável.

Aqueles que dizem 'não importa, use o que você gosta' não estão vendo a imagem toda. Todo mundo pega o código de outras pessoas em um ponto ou outro e precisa lidar com as decisões que tomou no momento em que o escreveu. É ruim o suficiente ter que lidar com convenções de nomes radicalmente diferentes ou - os estilos clássicos de fixação, sem adicionar a coisa toda ' varou não' à mistura. O pior caso é quando um programador não usou vare, em seguida, vem um mantenedor que o ama e estende o código usando-o. Então agora você tem uma bagunça profana.

Os padrões são uma coisa boa, precisamente porque eles significam que você tem muito mais chances de conseguir código aleatório e de entender rapidamente. Quanto mais coisas diferentes, mais difícil fica. E mudar para o estilo 'var em qualquer lugar' faz uma grande diferença.

Não me importo com digitação dinâmica e não me importo com digitação implícita - em idiomas projetados para eles. Eu gosto bastante de Python. Mas o C # foi projetado como uma linguagem estaticamente explícita e é assim que deve permanecer. Quebrar as regras para tipos anônimos já era ruim; deixar as pessoas levar isso ainda mais longe e quebrar ainda mais os idiomas da língua é algo com o qual não estou feliz. Agora que o gênio está fora da garrafa, ele nunca mais voltará. O C # ficará balcanizado em campos. Não é bom.

Muitas vezes durante o teste, eu me vejo tendo um código como este:

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

Agora, às vezes, quero ver o que o SomeOtherThing em si contém. SomeOtherThing não é o mesmo tipo que CallMethod () retorna. Já que estou usando var, apenas mudo isso:

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

para isso:

var something = myObject.SomeProperty.SomeOtherThing;

Sem var, eu teria que continuar alterando o tipo declarado também no lado esquerdo. Eu sei que é menor, mas é extremamente conveniente.

Para os aficionados que pensam que vareconomizam tempo, são necessárias menos teclas digitadas:

StringBuilder sb = new StringBuilder();

do que

var sb = new StringBuilder();

Conte-os se você não acredita em mim ...

19 versus 21

Vou explicar se for preciso, mas tente ... (dependendo do estado atual do seu intelecto, talvez seja necessário digitar mais alguns para cada um)

E é verdade para todos os tipos que você pode imaginar !!

Meu sentimento pessoal é que var nunca deve ser usado, exceto onde o tipo não é conhecido porque reduz a legibilidade do reconhecimento no código. O cérebro leva mais tempo para reconhecer o tipo do que uma linha completa. Os veteranos que entendem código de máquina e bits sabem exatamente do que estou falando. O cérebro processa em paralelo e, quando você usa var, força-o a serializar sua entrada. Por que alguém iria querer fazer seu cérebro trabalhar mais? É para isso que servem os computadores.

I divisão var todo os lugares, os lugares só questionáveis para mim são tipos de curto internos, por exemplo, eu prefiro int i = 3;maisvar i = 3;

Certamente isso pode simplificar as coisas, a partir do código que escrevi ontem:

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

Isso seria extremamente detalhado sem var.

Adendo: Um pouco de tempo gasto com uma linguagem com inferência de tipo real (por exemplo, F #) mostrará o quão bons são os compiladores em obter o tipo de expressões correto. Certamente, isso significa que tenho a tendência de usar varo máximo possível e o uso de um tipo explícito agora indica que a variável não é do tipo da expressão de inicialização.

Nenhuma, exceto que você não precisa escrever o nome do tipo duas vezes. http://msdn.microsoft.com/en-us/library/bb383973.aspx