Uso de la palabra clave var en C#

https://stackoverflow.com/questions/41479

09-06-2019
|

Pregunta

Después de discutir con colegas sobre el uso de la palabra clave 'var' en C# 3, me pregunté cuáles eran las opiniones de la gente sobre los usos apropiados de la inferencia de tipos mediante var.

Por ejemplo, utilicé var con bastante pereza en circunstancias cuestionables, por ejemplo: -

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.

Los usos más legítimos de var son los siguientes: -

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

Curiosamente, LINQ parece ser un área gris, por ejemplo: -

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

Está claro cuáles serán los resultados, ya que será un tipo que implemente IEnumerable, sin embargo, no es del todo obvio de la misma manera que lo es una var que declara un nuevo objeto.

Es aún peor cuando se trata de LINQ a objetos, por ejemplo: -

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

Esto no es mejor que el equivalente foreach(var item in someList) { // ...} equivalente.

Aquí existe una preocupación real sobre la seguridad de tipos; por ejemplo, si tuviéramos que colocar los resultados de esa consulta en un método sobrecargado que aceptara IEnumerable<int> e IEnumerable<double>, la persona que llama podría pasar sin darse cuenta el tipo incorrecto.

var hace mantenga una escritura fuerte, pero la pregunta es realmente si es peligroso que el tipo no sea inmediatamente evidente en la definición, algo que se magnifica cuando las sobrecargas significan que es posible que no se emitan errores del compilador cuando sin querer se pasa el tipo incorrecto a un método.

Solución

yo todavia pienso var puede hacer que el código sea más legible en algunos casos.Si tengo una clase Cliente con una propiedad Pedidos y quiero asignarla a una variable, simplemente haré esto:

var orders = cust.Orders;

No me importa si Customer.Orders es IEnumerable<Order>, ObservableCollection<Order> o BindingList<Order> - Todo lo que quiero es mantener esa lista en la memoria para iterar sobre ella u obtener su recuento o algo así más adelante.

Contraste la declaración anterior con:

ObservableCollection<Order> orders = cust.Orders;

Para mí, el nombre del tipo es sólo ruido.Y si vuelvo atrás y decido cambiar el tipo de Cliente, los pedidos en el futuro (por ejemplo, desde ObservableCollection<Order> a IList<Order>) entonces también necesito cambiar esa declaración, algo que no tendría que hacer si hubiera usado var en primer lugar.

Otros consejos

yo suelo var extensamente.Ha habido críticas de que esto disminuye la legibilidad del código, pero no hay argumentos que respalden esa afirmación.

Es cierto que esto puede significar que no está claro a qué tipo nos enfrentamos.¿Así que lo que?En realidad, este es el objetivo de un diseño desacoplado.Cuando se trata de interfaces, es enfático no interesado en el tipo que tiene una variable. var lleva esto mucho más allá, es cierto, pero creo que el argumento sigue siendo el mismo desde el punto de vista de la legibilidad:En realidad, el programador no debería estar interesado en el tipo de variable sino en qué variable hace.Es por eso que Microsoft también llama a la inferencia de tipos "escritura de pato".

Entonces, ¿qué hace una variable cuando la declaro usando var?Fácil, hace todo lo que IntelliSense me dice que haga.Cualquier razonamiento sobre C# que ignore el IDE no se ajusta a la realidad.En la práctica, cada código C# se programa en un IDE que admite IntelliSense.

Si estoy usando un var variable declarada y me confundo para qué sirve la variable, hay algo fundamentalmente incorrecto en mi código. var no es la causa, sólo hace visibles los síntomas.No culpes al mensajero.

Ahora, el equipo de C# ha publicado una guía de codificación que establece que var debería solo usarse para capturar el resultado de una declaración LINQ que crea un tipo anónimo (porque aquí, no tenemos una alternativa real a var).Bueno, al diablo con eso.Mientras el equipo de C# no me dé un argumento sólido para esta directriz, la ignoraré porque, en mi opinión profesional y personal, es pura tontería.(Lo siento;No tengo ningún enlace a la directriz en cuestión).

En realidad, hay algunos (superficialmente) buenas explicaciones sobre por qué no deberías usar var pero sigo creyendo que en gran medida están equivocados.Tomemos el ejemplo de "capacidad de búsqueda":el autor afirma que var dificulta la búsqueda de lugares donde MyType se utiliza.Bien.También lo hacen las interfaces.En realidad, ¿por qué querría saber dónde se usa la clase?Podría estar más interesado en dónde se crea una instancia y esto aún se podrá buscar porque en algún lugar se debe invocar su constructor (incluso si esto se hace indirectamente, el nombre del tipo debe mencionarse en alguna parte).

Var, en mi opinión, en C# es un Buena cosa^tm.Cualquier variable así escrita todavía está fuertemente tipada, pero obtiene su tipo del lado derecho de la asignación donde está definida.Debido a que la información de tipo está disponible en el lado derecho, en la mayoría de los casos, es innecesario y demasiado detallado tener que ingresarla también en el lado izquierdo.Creo que esto aumenta significativamente la legibilidad sin disminuir la seguridad de los tipos.

Desde mi punto de vista, utilizar buenas convenciones de nomenclatura para variables y métodos es más importante desde el punto de vista de la legibilidad que la información de tipo explícita.Si necesito información de tipo, siempre puedo pasar el cursor sobre la variable (en VS) y obtenerla.Sin embargo, en general, el lector no debería necesitar información de tipo explícita.Para el desarrollador, en VS todavía obtiene Intellisense, independientemente de cómo se declare la variable.Habiendo dicho todo esto, todavía puede haber casos en los que tenga sentido declarar explícitamente el tipo; tal vez tenga un método que devuelva un List<T>, pero quieres tratarlo como un IEnumerable<T> en tu método.Para asegurarse de que está utilizando la interfaz, declarar la variable del tipo de interfaz puede hacer esto explícito.O, tal vez, desee declarar una variable sin un valor inicial, porque inmediatamente obtiene un valor basado en alguna condición.En ese caso necesitas el tipo.Si la información del tipo es útil o necesaria, continúe y úsela.Sin embargo, creo que normalmente no es necesario y que el código es más fácil de leer sin él en la mayoría de los casos.

Ninguna de esas cosas es absolutamente cierta; var puede tener efectos tanto positivos como negativos sobre la legibilidad.En mi opinión, var debe usarse cuando cualquiera de las siguientes condiciones es cierta:

El tipo es anónimo (bueno, aquí no tienes otra opción, ya que debe ser var en este caso)
El tipo es obvio según la expresión asignada (es decir, var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

var no tiene impactos en el rendimiento, ya que es azúcar sintáctico;el compilador infiere el tipo y lo define una vez compilado en IL;no hay nada de hecho dinámico al respecto.

De Eric Lippert, ingeniero senior de diseño de software del equipo de C#:

¿Por qué fue el var ¿Se introdujo la palabra clave?

Hay dos razones, una que existe hoy, una que surgirá en 3.0.

La primera razón es que este código es increíblemente feo debido a toda la redundancia:

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

Y ese es un ejemplo simple: he escrito peor.Cada vez que te vean obligado a escribir exactamente lo mismo dos veces, es una redundancia que podemos eliminar.Mucho mejor escribir

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

Y deje que el compilador descubra cuál se basa el tipo en la tarea.

Segundo, C# 3.0 presenta tipos anónimos.Dado que los tipos anónimos por definición no tienen nombres, necesidad Para poder inferir el tipo de variable de la expresión de inicialización si su tipo es anónimo.

El énfasis es mío.Todo el artículo, C# 3.0 todavía se escribe estáticamente, ¡honesto!, y el consiguiente serie son bastante buenos.

Esto es lo que var es para.Otros usos probablemente no funcionen tan bien.Cualquier comparación con JScript, VBScript o escritura dinámica es una tontería total.Tenga en cuenta de nuevo, var es requerido para que otras características funcionen en .NET.

Creo que el uso de var debería combinarse con nombres de variables sabiamente elegidos.

No tengo ningún problema en usar var en una declaración foreach, siempre que no sea así:

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

Si fuera más así:

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

...entonces sería mucho más probable que alguien que leyera el código entendiera qué es "lista".Si tiene control sobre el nombre de la variable de lista, eso es aún mejor.

Lo mismo puede aplicarse a otras situaciones.Esto es bastante inútil:

var x = SaveFoo(foo);

...pero esto tiene sentido:

var saveSucceeded = SaveFoo(foo);

Cada uno con lo suyo, supongo.Me encontré haciendo esto, lo cual es una locura:

var f = (float)3;

Necesito algún tipo de programa var de 12 pasos.Mi nombre es Matt y uso (ab) var.

Hemos adoptado el espíritu de "Código para personas, no para máquinas", basado en el supuesto de que se pasa mucho más tiempo en modo de mantenimiento que en nuevos desarrollos.

Para mí, eso descarta el argumento de que el compilador "sabe" de qué tipo es la variable; claro, no puede escribir código no válido la primera vez porque el compilador detiene la compilación del código, pero cuando el siguiente desarrollador lee el código en 6 meses deben poder deducir qué está haciendo la variable correcta o incorrectamente e identificar rápidamente la causa de los problemas.

De este modo,

var something = SomeMethod();

está prohibido por nuestros estándares de codificación, pero en nuestro equipo recomendamos lo siguiente porque aumenta la legibilidad:

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

No está mal, es más una cuestión estilística, que tiende a ser subjetiva.Puede agregar inconsistencias cuando usas var y cuando no.

Otro caso preocupante, en la siguiente llamada no se puede saber con solo mirar el código el tipo devuelto por CallMe:

var variable = CallMe();

Esa es mi principal queja contra var.

Utilizo var cuando declaro delegados anónimos en métodos, de alguna manera var parece más limpio que si usara Func.Considere este código:

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

EDITAR:Se actualizó el último ejemplo de código basado en la entrada de Julian.

Var no se parece en nada a una variante.La variable todavía está fuertemente tipada, solo que no presionas teclas para que quede así.Puede pasar el cursor sobre él en Visual Studio para ver el tipo.Si estás leyendo código impreso, es posible que tengas que pensar un poco para determinar cuál es el tipo.Pero solo hay una línea que lo declara y muchas líneas que lo usan, por lo que darle nombres decentes a las cosas sigue siendo la mejor manera de hacer que su código sea más fácil de seguir.

¿Usar Intellisense es perezoso?Se escribe menos que el nombre completo.¿O hay cosas que requieren menos trabajo pero que no merecen críticas?Creo que los hay, y var es uno de ellos.

El momento más probable en el que necesitarás esto es para tipos anónimos (donde es 100% obligatorio);pero también evita la repetición en casos triviales y, en mi opinión, la línea es más clara.No necesito ver el tipo dos veces para una inicialización simple.

Por ejemplo:

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

(Por favor, no edite el hscroll de arriba, ¡¡¡eso prueba el punto!!!)

frente a:

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

Sin embargo, hay ocasiones en las que esto es engañoso y puede causar errores.Tenga cuidado al usar var si la variable original y el tipo inicializado no fueran idénticos.Por ejemplo:

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 caso específico donde var es difícil:revisiones de código fuera de línea, especialmente las realizadas en papel.

No puedes confiar en pasar el mouse para eso.

No veo cual es el problema..

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

Todavía tienes inteligencia completa sobre "algo" y, para cualquier caso ambiguo, tienes tus pruebas unitarias, ¿verdad?( ¿Tú?)

No es varchar, no es tenue y ciertamente no es una escritura dinámica o débil.Está parando locuras como esta:

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

y reducir ese desorden mental total a:

var v = new List<somethinglongtypename>();

Bonito, no tan bonito como:

v = List<somethinglongtypename>();

Pero entonces eso es lo que Abucheo es para.

Si alguien está usando el var palabra clave porque no quieren "descubrir el tipo", esa es definitivamente la razón equivocada.El var La palabra clave no crea una variable con un tipo dinámico, el compilador aún tiene que conocer el tipo.Como la variable siempre tiene un tipo específico, el tipo también debe ser evidente en el código si es posible.

Buenas razones para utilizar el var palabras clave son por ejemplo:

Donde sea necesario, es decirpara declarar una referencia para un tipo anónimo.
Donde hace que el código sea más legible, es decir.eliminar declaraciones repetitivas.

Escribir el tipo de datos a menudo hace que el código sea más fácil de seguir.Muestra qué tipos de datos está utilizando, de modo que no tenga que averiguar el tipo de datos averiguando primero qué hace el código.

Dado lo poderoso que es Intellisense ahora, no estoy seguro de que var sea más difícil de leer que tener variables miembro en una clase o variables locales en un método que están definidas fuera del área visible de la pantalla.

Si tiene una línea de código como

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

Es mucho más fácil o más difícil de leer que:

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

Creo que la clave con el VAR es usarlo sólo cuando sea apropiado, es decir.al hacer cosas en Linq que facilite (y probablemente en otros casos).

si tienes consiguió un tipo para algo en el entonces deberías usarlo; no hacerlo es simple pereza (a diferencia de la pereza creativa que generalmente se debe fomentar; los buenos programadores a menudo trabajan muy duro para ser perezosos y podrían considerarse la fuente de la cosa). en primer lugar).

En primer lugar, una prohibición general es tan mala como abusar de la construcción, pero es necesario que exista un estándar de codificación sensato.

La otra cosa a recordar es que no es una var de tipo VB en el sentido de que no puede cambiar los tipos; es una variable fuertemente tipada es solo que se infiere el tipo (razón por la cual hay personas que argumentarán que no es irrazonable usarla, digamos, en un foreach, pero no estoy de acuerdo por razones de legibilidad y mantenibilidad).

Sospecho que este se ejecutará y ejecutará (-:

Murph

Seguro, int es fácil, pero cuando el tipo de variable es IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var hace las cosas mucho más fáciles.

Robado de la publicar sobre este tema en CodingHorror:

Desafortunadamente, usted y todos los demás se equivocaron.Si bien estoy de acuerdo con usted en que la redundancia no es algo bueno, la mejor manera de resolver este problema hubiera sido hacer algo como lo siguiente:

MiObjeto m = nuevo();

O si está pasando parámetros:

Persona p = new("Nombre", "Apellido);

Donde, al crear un nuevo objeto, el compilador infiere el tipo del lado izquierdo y no del derecho.Esto tiene otras ventajas sobre "var", ya que también podría usarse en declaraciones de campo (también hay otras áreas en las que podría ser útil, pero no entraré en eso aquí).

Al final, simplemente no se pretendía reducir la redundancia.No me malinterpretes, "var" es MUY importante en C# para tipos/proyecciones anónimos, pero el uso aquí está MUY alejado (y he estado diciendo esto durante mucho, mucho tiempo) ya que ofuscas el tipo que esta siendo usado.Tener que escribirlo dos veces es demasiado frecuente, pero declararlo cero veces es muy poco.

Nicholas Paldino .NET/C# MVP el 20 de junio de 2008 08:00 a.m.

Supongo que si tu principal preocupación es tener que escribir menos, entonces no hay ningún argumento que te impida usarlo.

Si solo vas a alguna vez Sea la persona que mira su código, entonces ¿a quién le importa?De lo contrario, en un caso como este:

var people = Managers.People

está bien, pero en un caso como este:

var fc = Factory.Run();

provoca un cortocircuito en cualquier deducción de tipo inmediato que mi cerebro pueda empezar a formar a partir del "inglés" del código.

De lo contrario, utilice su mejor criterio y la "cortesía" de programación hacia otras personas que puedan tener que trabajar en su proyecto.

Usando var en lugar de tipo explícito hace que las refactorizaciones sean mucho más fáciles (por lo tanto, debo contradecir a los carteles anteriores que querían decir que no hacía ninguna diferencia o que era puramente "azúcar sintáctico").

Puede cambiar el tipo de retorno de sus métodos sin cambiar cada archivo donde se llama a este método.Imaginar

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

que se usa como

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

Si quisieras refactorizar SomeMethod() devolver un IEnumerable<MySecondClass>, tendrías que cambiar la declaración de la variable (también dentro del foreach) en cada lugar donde utilizó el método.

Si tú escribes

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

en cambio, no es necesario cambiarlo.

@aku:Un ejemplo son las revisiones de código.Otro ejemplo son los escenarios de refactorización.

Básicamente, no quiero buscar tipos con el mouse.Puede que no esté disponible.

Es una cuestión de gustos.Todo este alboroto por el tipo de una variable desaparece cuando te acostumbras a los lenguajes escritos dinámicamente.Eso es, si alguna vez te empiezan a gustar (no estoy seguro de que a todos les gusten, pero a mí sí).

C# var es bastante bueno en eso aspecto como escritura dinámica, pero en realidad es estático escribiendo: el compilador impone un uso correcto.

El tipo de variable no es realmente tan importante (esto se ha dicho antes).Debería quedar relativamente claro por el contexto (sus interacciones con otras variables y métodos) y su nombre; no espere lista de clientes contener un int...

Todavía estoy esperando a ver qué piensa mi jefe sobre este asunto. Recibí un "adelante" general para usar cualquier construcción nueva en 3.5, pero ¿qué haremos con el mantenimiento?

En tu comparación entre IEnumerable<int> y IEnumerable<double> no necesita preocuparse: si pasa el tipo incorrecto, su código no se compilará de todos modos.

No hay preocupación por la seguridad de tipos, ya que var es no dinámica.Es simplemente magia del compilador y cualquier tipo de llamada insegura que realice será detectada.

Var es absolutamente necesario para 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
    };

Ahora mira anonEnumeración en intellisense y 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
}

El compilador de C# es bastante inteligente: los tipos anónimos generados por separado tendrán el mismo tipo generado si sus propiedades coinciden.

Fuera de eso, siempre que tengas intellisense tiene sentido usar var en cualquier lugar el contexto es 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;

Supongo que depende de tu perspectiva.Personalmente, nunca he tenido dificultades para entender un fragmento de código debido a var "mal uso", y mis compañeros de trabajo y yo lo usamos bastante en todas partes.(Estoy de acuerdo en que Intellisense es una gran ayuda en este sentido). Lo agradezco como una forma de eliminar la información repetitiva.

Después de todo, si declaraciones 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

Si fueran realmente tan imposibles de manejar, nadie usaría lenguajes escritos dinámicamente.

Solo uso var cuando está claro qué tipo se usa.

Por ejemplo, usaría var en este caso, porque puedes ver inmediatamente que x será del tipo "MiClase":

var x = new MyClass();

NO usaría var en casos como este, porque tienes que arrastrar el mouse sobre el código y mirar la información sobre herramientas para ver qué tipo devuelve MyFunction:

var x = MyClass.MyFunction();

Especialmente, yo nunca use var en los casos en que el lado derecho ni siquiera sea un método, sino solo un valor:

var x = 5;

(porque el compilador no puede saber si quiero un byte, short, int o lo que sea)

Para mí, la antipatía hacia var ilustra por qué el bilingüismo en .NET es importante.Para aquellos programadores de C# que también hayan hecho VB .NET, las ventajas de var son intuitivamente obvios.La declaración estándar de C# de:

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

es el equivalente, en VB .NET, de escribir esto:

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

Sin embargo, nadie hace eso en VB .NET.Sería una tontería hacerlo, porque desde la primera versión de .NET has podido hacer esto...

Dim whatever As New List(Of String)

...que crea la variable y la inicializa todo en una línea razonablemente compacta.Ah, pero ¿y si quieres un IList<string>, No un List<string>?Bueno, en VB .NET eso significa que tienes que hacer esto:

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

Justo como tendrías que hacer en C#, y obviamente no podrías usar var para:

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

Si usted necesidad el tipo para ser algo diferente, puede ser.Pero uno de los principios básicos de una buena programación es reducir la redundancia, y eso es exactamente lo que hace var.

Úselo para tipos anónimos: para eso está.Cualquier otra cosa es inútil.Como muchas personas que crecieron en C, estoy acostumbrado a buscar el tipo en la izquierda de la declaración.No miro al lado derecho a menos que sea necesario.Usando var porque cualquier declaración antigua me hace hacer eso todo el tiempo, lo que personalmente me resulta incómodo.

Aquellos que dicen "no importa, usa lo que te guste" no están viendo el panorama completo.Todos tomarán el código de otras personas en un momento u otro y tendrán que lidiar con las decisiones que tomaron en el momento en que lo escribieron.Ya es bastante malo tener que lidiar con convenciones de nomenclatura radicalmente diferentes, o (la queja clásica) estilos de refuerzo, sin agregar el conjunto 'var o no en la mezcla.El peor caso será cuando un programador no usó var y luego llega un mantenedor al que le encanta y amplía el código usándolo.Así que ahora tienes un desastre impío.

Los estándares son algo bueno precisamente porque significan que es mucho más probable que puedas captar código aleatorio y asimilarlo rápidamente.Cuantas más cosas sean diferentes, más difícil se vuelve.Y pasar al estilo 'var en todas partes' crea una grande diferencia.

No me importa la escritura dinámica ni la escritura implícita, en idiomas diseñados para ellos.Me gusta bastante Python.Pero C# fue diseñado como un lenguaje estáticamente tipificado explícitamente y así es como debería permanecer.Romper las reglas para tipos anónimos ya era bastante malo;Dejar que la gente vaya aún más lejos y rompa aún más los modismos del idioma es algo con lo que no estoy contento.Ahora que el genio salió de la botella, nunca volverá a entrar.C# se balcanizará en campos.No es bueno.

Muchas veces durante las pruebas, me encuentro con un código como este:

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

Ahora, a veces, querré ver qué contiene SomeOtherThing, SomeOtherThing no es el mismo tipo que devuelve CallMethod().Como estoy usando var, simplemente cambio esto:

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

a esto:

var something = myObject.SomeProperty.SomeOtherThing;

Sin var, también tendría que seguir cambiando el tipo declarado en el lado izquierdo.Sé que es menor, pero es extremadamente conveniente.

Para los aficionados que piensan var ahorra tiempo, se necesitan menos pulsaciones de teclas para escribir:

StringBuilder sb = new StringBuilder();

que

var sb = new StringBuilder();

Cuéntalos si no me crees...

19 contra 21

Te lo explicaré si es necesario, pero inténtalo...(dependiendo del estado actual de tu intellisense es posible que tengas que escribir un par más para cada uno)

¡¡Y es cierto para todos los tipos que puedas imaginar!!

Mi sensación personal es que var nunca debería usarse excepto cuando no se conoce el tipo porque reduce la legibilidad del reconocimiento en el código.Al cerebro le toma más tiempo reconocer el tipo que una línea completa.Los veteranos que entienden el código de máquina y los bits saben exactamente de qué estoy hablando.El cerebro procesa en paralelo y cuando usas var lo obligas a serializar su entrada.¿Por qué alguien querría hacer que su cerebro trabajara más duro?Para eso están las computadoras.

Dividí var por todos los lugares, los únicos lugares cuestionables para mí son los tipos cortos internos, p.yo prefiero int i = 3; encima var i = 3;

Ciertamente puede simplificar las cosas, según el código que escribí ayer:

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

Esto habría sido extremadamente detallado sin var.

Apéndice:Un poco de tiempo dedicado a un idioma con real inferencia de tipos (p. ej.F#) mostrará cuán buenos son los compiladores para obtener el tipo correcto de expresiones.Ciertamente ha significado que tiendo a usar var tanto como puedo, y usar un tipo explícito ahora indica que la variable no es del tipo de expresión de inicialización.

Ninguno, excepto que no es necesario escribir el nombre del tipo dos veces. http://msdn.microsoft.com/en-us/library/bb383973.aspx

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow