Uso da palavra-chave var em C#
https://stackoverflow.com/questions/41479
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Após a discussão com os colegas sobre o uso do 'var' palavra-chave no C# 3 eu me perguntava o que opiniões de pessoas estavam na utilização mais adequada do tipo de inferência através de var?
Por exemplo, eu, ao invés de preguiçosamente usado 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.
Mais utilizações legítimas do var são como segue:-
var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.
Curiosamente 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.
É claro que os resultados serão em que ele vai ser um tipo que implementa IEnumerable, no entanto, ele não é inteiramente óbvio da mesma forma que um var declarando um novo objeto.
É ainda pior quando se trata do LINQ to objects, por exemplo:-
var results = from item in someList
where item != 3
select item;
Isto não é melhor do que o equivilent foreach(var item in someList) { // ...} equivilent.
Há uma real preocupação com a segurança de tipo aqui, por exemplo, se fosse para colocar os resultados da consulta em um método sobrecarregado que aceitou IEnumerable<int> e IEnumerable<double> o chamador pode, inadvertidamente, passar o tipo errado.
var não manter forte, mas a questão é, realmente, se é perigoso para o tipo para não ser imediatamente aparente na definição, algo que é ampliada quando sobrecargas média de erros do compilador pode não ser emitido quando você inadvertidamente, passar o tipo errado para um método.
Solução
Eu ainda acho que var pode tornar o código mais legível, em alguns casos.Se eu tenho uma classe de Cliente com uma propriedade de Pedidos, e eu quero que atribuir a uma variável, que eu só vou fazer isso:
var orders = cust.Orders;
Eu não me importo se o Cliente.Encomendas IEnumerable<Order>, ObservableCollection<Order> ou BindingList<Order> - tudo o que eu quero é manter essa lista na memória para iterar sobre ele ou obter a sua contagem ou algo mais tarde.
Contraste 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 Cliente.As encomendas para baixo da faixa (digamos, a partir de ObservableCollection<Order> para IList<Order>) então eu preciso mudar essa declaração também - algo que eu não teria que fazer se eu tinha usado var em primeiro lugar.
Outras dicas
Eu uso var extensivamente.Houve críticas de que isso diminui a legibilidade do código, mas nenhum argumento para apoiar essa alegação.
É verdade, pode significar que ele não é claro que tipo estamos a lidar.Então, o que?Este é realmente o ponto de um desmembrado de design.Ao lidar com as interfaces são enfaticamente não interessado no tipo de uma variável tem. var leva isso muito mais, é verdade, mas eu acho que o argumento permanece o mesmo a partir de uma legibilidade ponto de vista:O programador não deveria ser, na verdade, interessado no tipo da variável, mas sim em que uma variável não.É por isso que a Microsoft também chamadas de inferência de tipo de "duck typing."
Então, o que é uma variável de fazer quando eu declarar-lo usando var?Fácil, ele faz tudo o que o IntelliSense diz-me que não.Qualquer raciocínio sobre C# que ignora o IDE aquém da realidade.Na prática, cada código C# é programado em uma IDE, que oferece suporte a IntelliSense.
Se eu estou usando um var variável declarada e ficar confuso que a variável é não para, há algo fundamentalmente errado com o meu código. var não é a causa, ele apenas faz com que os sintomas visíveis.Não culpe o mensageiro.
Agora, a equipe do C# lançou uma codificação de orientação, informando que var deve apenas ser usado para capturar o resultado de uma instrução LINQ que cria um tipo anônimo (porque aqui, nós não temos nenhuma alternativa real para var).Bem, que se dane.Enquanto a equipe do C# não me dá um som argumento para essa diretriz, vou ignorá-lo, porque na minha profissional e pessoal opinião, é pura bobagem.(Desculpe;Eu não tenho ligação à diretriz em questão.)
Na verdade, existem alguns (superficialmente) boas explicações por que você não deve usar var mas eu ainda acredito que eles são em grande parte errado.Tome-se o exemplo de "searchabililty":o autor afirma que var o que dificulta a busca de lugares onde MyType é usada.Direito.Para fazer interfaces.Na verdade, por que eu iria querer saber onde a classe é usada?Eu poderia estar mais interessado em onde ele é instanciado e isso ainda será pesquisável, porque em algum lugar de seu construtor tem de ser invocada (mesmo se isso é feito indiretamente, o nome de tipo tem de ser mencionado em algum lugar).
Var, na minha opinião, em C# é uma coisa boatm.Qualquer variável de forma que escreveu ainda é fortemente tipada, mas ele recebe o tipo do lado direito da atribuição de onde ele está definido.Porque o tipo de informação está disponível no lado direito, na maioria dos casos, é desnecessário e excessivamente detalhado para também ter a introduzi-lo no lado esquerdo.Eu acho que isso aumenta significativamente a legibilidade sem diminuir a segurança de tipos.
Do meu ponto de vista, usando o bom convenções de atribuição de nomes para as variáveis e métodos é mais importante a partir de uma legibilidade perspectiva do que explícito o tipo de informações.Se eu precisar de informações do tipo, eu sempre posso passar o mouse sobre a variável (no VS) e obtê-lo.Geralmente, porém, explícita tipo de informação não deve ser necessário para o leitor.Para o desenvolvedor, no VS você ainda obter o Intellisense, independentemente de como a variável é declarada.Tendo dito tudo isso, ainda pode haver casos em que não faz sentido declarar explicitamente o tipo -- talvez você tem um método que retorna um List<T>, mas você quer tratá-lo como um IEnumerable<T> em seu método.Para garantir que você está usando a interface, declarando a variável do tipo de interface pode fazer isso explicitamente.Ou, talvez, você quer declarar uma variável sem um valor inicial -- porque ele imediatamente recebe um valor baseado em alguma condição.Nesse caso, você precisa do tipo.Se o tipo de informação é útil ou necessário, vá em frente e usá-lo.Sinto, porém, que, normalmente, não é necessário e o código é mais fácil de ler sem ele na maioria dos casos.
Nenhum deles é absolutamente verdadeiro; var pode ter tanto efeitos positivos e negativos sobre a legibilidade.Na minha opinião, var devem ser utilizados quando qualquer uma das seguintes condições for verdadeira:
- O tipo é anônimo (bem, você não tem nenhuma escolha aqui, como deve ser var neste caso)
- O tipo é óbvio baseado na expressão designado (i.e.
var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())
var não tem impactos no desempenho, como é um açúcar sintático;o compilador infere o tipo e a define, uma vez que é compilado em IL;não há nada na verdade, dinâmica sobre ele.
A partir de Eric Lippert, um Software Sênior Engenheiro de projetos na equipe do C#:
Qual foi o var palavra-chave introduzida?
Existem duas razões, uma que existe hoje, um que vai surgir no 3.0.
A primeira razão é que este código é incrivelmente feio por causa de todas as redundância:
Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();E esse é um exemplo simples – eu escrito pior.A qualquer momento você é forçado digitar exatamente a mesma coisa duas vezes, isso é uma redundância que podemos remover.Muito mais agradável para se escrever
var mylists = new Dictionary<string,List<int>>();e deixar que o compilador descobrir o que o tipo é baseado na atribuição de.
Segundo, o C# 3.0 introduz anônimo tipos.Desde tipos anônimos definição não têm nomes, você necessidade para ser capaz de inferir o tipo da variável de inicialização a expressão se seu tipo é anônimo.
Ênfase minha.O artigo inteiro, C# 3.0 ainda é estaticamente tipada, honesto!, e o que se seguiu série são muito bons.
Isto é o que var é para isso.Outros usos provavelmente não vai funcionar tão bem.Qualquer comparação com JScript, VBScript, ou tipagem dinâmica é total beliche.Nota novamente, var é necessário a fim de ter algumas outras características de trabalho .LÍQUIDA.
Eu acho que o uso de var deve ser juntamente com sabiamente escolhidos nomes de variáveis.
Eu não tenho nenhum problema com a utilização do var em uma instrução foreach, desde que ele não é como este:
foreach (var c in list) { ... }
Se fosse mais parecido com este:
foreach (var customer in list) { ... }
...em seguida, alguém lendo o código seria muito mais propensos a entender o que a "lista" é.Se você tem controle sobre o nome da variável da lista em si, o que é ainda melhor.
O mesmo pode se aplicar a outras situações.Isso é muito inútil:
var x = SaveFoo(foo);
...mas isso faz sentido:
var saveSucceeded = SaveFoo(foo);
Cada um para o seu lado, eu acho.Eu me encontrei de fazer isso, que é simplesmente uma loucura:
var f = (float)3;
Eu preciso de algum tipo, de 12 de passo var programa.Meu nome é Matt, e eu (ab)uso do var.
Temos adotado o ethos "Código para as pessoas, não máquinas", com base na suposição de que você passar várias vezes mais no modo de manutenção do que no novo desenvolvimento.
Para mim, que regras o argumento de que o compilador "sabe" que tipo de variável é - certo, você não pode escrever código inválido primeira vez, porque o compilador deixa seu código de compilação, mas quando o próximo desenvolvedor que está lendo o código em 6 meses, tempo necessário para ser capaz de deduzir que a variável está fazendo corretamente ou incorretamente e rapidamente identificar a causa de problemas.
Assim,
var something = SomeMethod();
é proibida pelos nossos padrões de codificação, mas a seguinte é incentivada em nossa equipe, porque ele aumenta a legibilidade:
var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
DoWork( item );
}
Não é ruim, é mais uma estilística coisa, o que tende a ser subjetiva.Pode adicionar inconsistências, quando você usar var e quando não.
Outro caso de preocupação, na chamada seguinte, você não pode dizer simplesmente olhando o código o tipo retornado pelo CallMe:
var variable = CallMe();
Essa é a minha principal queixa contra var.
Eu uso var quando eu declarar anônimo delegados em métodos, de alguma forma, var parece mais limpo do que se eu tivesse de usar Func.Considere este código:
var callback = new Func<IntPtr, bool>(delegate(IntPtr hWnd) {
...
});
EDITAR:Atualizado o último exemplo de código com base no calendário Juliano de entrada do
Var não é como variante.A variável é ainda fortemente tipados, é só que você não pressione as teclas para obtê-lo dessa forma.Você pode passar o mouse sobre ele no Visual Studio para ver o tipo.Se você está lendo código impresso, é possível que você pode ter que pensar um pouco para saber a que tipo é.Mas não é apenas uma linha que declara que ele e muitas linhas que usá-lo, por isso, dar as coisas decente nomes ainda é a melhor forma de tornar o seu código mais fácil de seguir.
É usando o Intellisense preguiçoso?É menos digitação de todo o nome.Ou há coisas que são menos trabalho, mas não merece críticas?Eu acho que há, e o var é um deles.
O mais provável vez, você terá essa é para os tipos anônimos (onde ele é 100% necessário);mas também evita a repetição para os casos simples, e IMO faz a linha mais clara.Eu 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, ele meio que prova o ponto!!!)
vs:
var data = new Dictionary<string, List<SomeComplexType<int>>>();
Há, no entanto, ocasiões em que isso é enganosa, e pode causar erros.Ter cuidado com a utilização var se a variável original e inicializado tipo não eram 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 onde var é difícil:offline revisões de código, especialmente as feitas em papel.
Você não pode depender mouse-overs para isso.
Eu não vejo qual é o grande negócio é..
var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!
Você ainda tem total intellisense no 'algo', e para qualquer ambíguo caso de você ter seus testes de unidade, certo?( você?)
Não é varchar não é fraca, e certamente não é dinâmico ou fraco de digitação.Ele está parando maddnes como este:
List<somethinglongtypename> v = new List<somethinglongtypename>();
e a redução total de mindclutter para:
var v = new List<somethinglongtypename>();
Bom, não tão agradável como:
v = List<somethinglongtypename>();
Mas, em seguida, que é o que Boo é para isso.
Se alguém está usando o var palavra-chave, pois eles não querem "descobrir o tipo", que é, definitivamente, o motivo errado.O var palavra-chave não criar uma variável com um tipo dinâmico, o compilador ainda tem que 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 o var palavras-chave são, por exemplo:
- Onde é necessário, por exemplo,para declarar uma referência para um tipo anônimo.
- Onde torna o código mais legível, i.é.a remoção de repetetive declarações.
Escrever o tipo de dados, muitas vezes, torna o código mais fácil de seguir.Ele mostra os tipos de dados que você está usando, assim que você não tem que descobrir o tipo de dados a primeira a descobrir o que o código faz.
Dado o quão poderoso o Intellisense é agora, eu não estou certo de var é mais difícil de ler do que ter variáveis de membro em uma classe, ou variáveis locais de um método que são definidas fora da área visível da tela.
Se você tiver uma linha de código, tal como
IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();
É muito mais fácil ou mais difícil de ler que:
var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();
Eu acho que a chave coisa com VAR é só usá-lo quando apropriado, i.é.quando fazemos as coisas no Linq que facilita (e provavelmente em outros casos).
Se você já tem um tipo de algo, então você deve usá-lo para não fazê-lo é simples preguiça (como oposição a preguiça criativa que é, geralmente, a ser incentivado - bons programadores oft trabalho muito difícil de ser preguiçoso e pode ser considerada a origem da coisa, em primeiro lugar).
A proibição é tão má como a abusar de construir em primeiro lugar, mas não precisa ser um razoável padrão de codificação.
Outra coisa a se lembrar é que não é um VB tipo de var em que ele não pode alterar o tipo é é uma rigidez variável só que o tipo é inferido (é por isso que há pessoas que argumentam que não é razoável para usá-lo em, digamos, um foreach, mas eu discordo por uma questão de legibilidade e facilidade de manutenção).
Eu suspeito que isso está indo para executar e executar (-:
Murph
Com certeza, int é fácil, mas quando o tipo da variável é IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var , torna as coisas muito mais fácil.
Roubado do post sobre este assunto no CodingHorror:
Infelizmente, você e todos os outros praticamente entendeu errado.Enquanto eu concordo com você que a redundância não é uma coisa boa, a melhor maneira de resolver esse problema seria fazer algo parecido com o seguinte:
MyObject m = new();
Ou se você estiver de passagem de parâmetros:
Pessoa p = new("Nome", "Sobrenome);
Onde na criação de um novo objeto, o compilador infere o tipo do lado esquerdo e não o direito.Este tem outras vantagens sobre o "var", em que ele pode ser usado no campo de declarações bem (há também algumas outras áreas que poderiam ser úteis, bem como, mas eu não vou entrar aqui).
No final, ele simplesmente não se destina a reduzir a redundância.Não me interpretem mal, "var" é MUITO importante em C# para os tipos anônimos, projeções, mas o uso aqui é apenas fora de FORMA (e eu venho dizendo isso há muito, muito tempo) como você ofuscar o tipo que está sendo usado.Ter que digitá-lo duas vezes, demasiadas vezes, mas declarando que é zero vezes é demasiado poucos.
Nicholas Paldino .NET/C# MVP em junho 20, 2008 08:00 AM
Eu acho que se a sua principal preocupação é ter para escrever menos -, então não há qualquer argumento que vai de oscilação de o utilizar.
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
isto é bom, mas em um caso como este:
var fc = Factory.Run();
ele curtos-circuitos de qualquer tipo imediato deduções meu cérebro pudesse iniciar a formação de 'inglês' do código.
Caso contrário, basta usar seu melhor julgamento e de programação de 'cortesia' em relação aos outros que pode ter para trabalhar no seu projeto.
Usando var em vez de tipo explícito faz refatorações muito mais fácil (por isso devo contradizer a anterior cartazes que significava que não fez nenhuma diferença ou era puramente "açúcar sintático").
Você pode alterar o tipo de retorno dos métodos sem alterar todos os arquivos, onde este 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ê queria refatorar SomeMethod() para devolver um IEnumerable<MySecondClass>, você teria que alterar a declaração de variável (também dentro da foreach) em cada lugar 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 tem para mudá-lo.
@aku:Um exemplo é o de revisões de código.Outro exemplo é a refatoração cenários.
Basicamente, eu não quero ir-tipo de caça com o meu mouse.Ele pode não estar disponível.
É uma questão de gosto.Toda essa agitação sobre o tipo de uma variável desaparece quando você se acostumar a linguagens de tipo dinâmico.Que é, se você já começar a gostar deles (eu não tenho certeza se todo mundo pode, mas eu faço).
C#'s var é muito legal em que ele procura como tipagem dinâmica, mas, na verdade, é estática digitando - o compilador impõe o uso correto.
O tipo da variável não é realmente importante (isso já foi dito antes).Ele deve ser relativamente claro a partir do contexto de suas interações com outras variáveis e métodos) e o seu nome - não espere customerList para conter um int...
Eu ainda estou esperando para ver o que o meu chefe pensa sobre esse assunto - eu tenho um cobertor "vá em frente", para usar quaisquer novas construções em 3.5, mas o que podemos fazer sobre a manutenção?
Em sua comparação entre IEnumerable<int> e IEnumerable<double> você não precisa preocupar - se você passar o errado digite o seu código não irá compilar de qualquer maneira.
Não há nenhuma preocupação sobre a segurança de tipo, como var é não dinâmica.É apenas compilador magia e qualquer tipo de chamadas não seguras que você fizer vai ser pego.
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 olhar para anonEnumeration no intellisense e vai aparecer algo como 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
}
O compilador C# é muito inteligente - anon tipos gerados separadamente terá o mesmo tipo gerado se suas propriedades jogo.
Fora isso, contanto que você tenha o intellisense isso faz sentido usar var em qualquer contexto é 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 do seu ponto de vista.Eu, pessoalmente, nunca tiveram qualquer dificuldade de compreensão de um pedaço de código devido a var o "mau uso", e meus colegas de trabalho e eu uso-o bastante todo.(Concordo que o Intellisense é uma grande ajuda a este respeito.) Bem-vinda como uma maneira de remover repetitivo cruft.
Afinal, se afirmações do tipo:
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
foram realmente impossível de lidar, ninguém iria usar linguagens de tipo dinâmico.
Eu só uso var quando é claro para ver que tipo é usado.
Por exemplo, eu poderia usar var neste caso, como 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ê tem que arrastar o mouse sobre o código e olhar para a dica de ferramenta para ver que tipo de MyFunction retorna:
var x = MyClass.MyFunction();
Especialmente, Eu nunca use var nos casos em que o lado direito não é ainda um método, mas apenas um valor:
var x = 5;
(porque o compilador não pode saber, se eu quiser um byte, short, int ou qualquer que seja)
Para mim, a antipatia em relação var ilustra por que o bilinguismo em .NET é importante.Para aqueles C# programadores que também tem feito VB .NET, as vantagens de var são óbvios.O padrão C# declaração de:
List<string> whatever = new List<string>();
é o equivalente, em VB .NET, de escrever esta:
Dim whatever As List(Of String) = New List(Of String)
Ninguém faz isso em VB .NET, no entanto.Seria tolice, porque desde a primeira versão .NET, você foi capaz de fazer isso...
Dim whatever As New List(Of String)
...que cria a variável e o inicializa todos em um razoavelmente compacto da linha.Ah, mas se você quiser um IList<string>, não List<string>?Bem, no VB .LÍQUIDO que significa que você tem para fazer isso:
Dim whatever As IList(Of String) = New List(Of String)
Exatamente como você gostaria de ter para fazer em C#, e, obviamente, não podia usar var para:
IList<string> whatever = new List<string>();
Se você necessidade o tipo de ser algo diferente, pode ser.Mas um dos princípios básicos de uma boa programação é reduzir a redundância, e que é exatamente o que o var não.
Use-a para tipos anônimos - que é o que ele está lá para.Qualquer outra coisa é um uso muito longe.Como muitas pessoas que cresceram em C, eu estou acostumado a olhar para a esquerda da declaração para o tipo.Eu não olhe para o lado direito, a menos que eu tenho que fazer.Usando var para qualquer idade declaração me faz fazer isso o tempo todo, que eu pessoalmente acho desconfortável.
Aqueles dizendo: 'não importa, use o que você está feliz com o' não está vendo a imagem inteira.Todos vão pegar o código de outras pessoas em um ponto ou outro e tem que lidar com decisões que eles fizeram no momento em que o escreveu.É ruim o suficiente ter que lidar com radicalmente diferentes convenções de nomenclatura, ou - o clássico queixa - órtese estilos, sem a adição de todo o 'var ou não' coisa na mistura.O pior caso é quando um programador não usar var e então chega um mantenedor que ama ele, e estende o código usando ele.Então, agora você tem um profano bagunça.
Os padrões são uma coisa boa, precisamente porque não quer dizer que você está muito mais susceptível de ser capaz de pegar código aleatório e ser capaz de grok-lo rapidamente.Por mais que as coisas que são diferentes, mais duro que fica.E movendo-se para a 'var de qualquer lugar" estilo faz um grande diferença.
Eu não me importo de tipagem dinâmica, e não me importo com o upn implícito escrever em línguas que lhes são destinados.Eu gosto muito de Python.Mas o C# foi concebido como um estaticamente explicitamente-linguagem e que é como ele deve ficar.Quebrar as regras para tipos anônimos era ruim o suficiente;deixar as pessoas terem que ainda mais e a quebra de expressões idiomáticas da língua, ainda mais, é algo que eu não sou feliz.Agora que o gênio saiu da garrafa, ela nunca vai voltar.C# vai se tornar balkanised em campos de concentração.Não é bom.
Muitos de tempo durante os testes, vejo-me na necessidade de código como este:
var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
Console.WriteLine(something);
Agora, às vezes, eu vou querer ver o que o SomeOtherThing em si contém, SomeOtherThing não é o mesmo tipo que CallMethod() retorna.Desde que eu estou usando var embora, eu só alterar isso:
var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
para isso:
var something = myObject.SomeProperty.SomeOtherThing;
Sem var, eu teria que ficar mudando a declaração do tipo do lado esquerdo também.Eu sei que é menor, mas é extremamente conveniente.
Para os apreciadores que pensar var economiza tempo, leva menos pressionamentos de teclas para digitar:
StringBuilder sb = new StringBuilder();
de
var sb = new StringBuilder();
Contagem em se você não acredita em mim...
19 versus 21
Eu vou explicar, se eu tenho, mas apenas experimentá-lo...(dependendo do estado atual de seu intellisense poderá ter de escrever mais um par para cada um)
E isso é verdadeiro para cada tipo que você pode pensar!!
Meu sentimento pessoal é de que o var deve nunca ser usada, exceto onde o tipo não é conhecido, pois reduz o reconhecimento readabiltiy no código.Ele leva o cérebro mais tempo para reconhecer o tipo de uma linha completa.Os velhotes que compreendem o código de máquina e bits de saber exatamente do que eu estou falando.O cérebro processa em paralelo, e quando você usar var forçar para serializar a sua entrada.Por que alguém iria querer fazer seu cérebro trabalhar mais?É isso que os computadores são destinados.
Vou dividir var todo os lugares, a única questionável lugares que para mim são internos a curto tipos, por exemplo,Eu prefiro int i = 3; mais var i = 3;
Ele pode, certamente, fazer as coisas mais simples, a partir do código que eu escrevi ontem:
var content = new Queue<Pair<Regex, Func<string, bool>>>();
...
foreach (var entry in content) { ... }
Isso teria de ser extremamente detalhado, sem var.
Adenda:Um pouco de tempo gasto com a língua, com o real tipo de inferência (por exemplo,F#) vai mostrar o quão bom compiladores são no sentido de conseguir o tipo de expressões.Certamente significava que eu tendem a usar var tanto quanto eu posso, e usando um tipo explícito agora indica que a variável não é de iniciar expressão do tipo.
Nenhuma, exceto que você não tem que escrever o nome do tipo duas vezes. http://msdn.microsoft.com/en-us/library/bb383973.aspx
