Uso de la palabra clave var en C #

Después de una discusión con colegas sobre el uso de la palabra clave 'var' en C # 3, me pregunté qué opiniones tenían las personas sobre los usos apropiados de la inferencia de tipos a través de var.

Por ejemplo, usé vagamente var 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 qué resultados habrá en que será un tipo que implemente IEnumerable, sin embargo, no es del todo obvio de la misma manera que 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 equitativo foreach (elemento var en someList) {// ...} equivilent.

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

var no mantener la tipificación estricta, pero la pregunta es si realmente es peligroso para el tipo a no ser evidente de inmediato en la definición, algo que se magnifica cuando sobrecargas errores medios compilador no pueden ser emitidos cuando se pasa involuntariamente el tipo incorrecto de un método.

Todavía creo que varpuede hacer que el código sea más legible en algunos casos. Si tengo una clase de Cliente con una propiedad de Órdenes, 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 más adelante.

Contraste la declaración anterior con:

ObservableCollection<Order> orders = cust.Orders;

Para mí, el nombre del tipo es solo ruido. Y si vuelvo y decido cambiar el tipo de Cliente. Ordena por el camino (digamos de 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 el primer sitio.

Yo uso varampliamente. Ha habido críticas de que esto disminuye la legibilidad del código, pero no hay argumento para apoyar esa afirmación.

Es cierto que puede significar que no está claro con qué tipo estamos tratando. ¿Y qué? Este es en realidad el objetivo de un diseño desacoplado. Cuando se trata de interfaces, no le interesa enfáticamente el tipo que tiene una variable. varaprovecha esta mucho más lejos, es cierto, pero creo que el argumento sigue siendo el mismo desde el punto de vista de la legibilidad: El programador no debe realmente estar interesado en el tipo de la variable, sino más bien en lo que una variable lo hace . Esta es la razón por la cual Microsoft también llama a la inferencia de tipos "duck typing".

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

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

Ahora, el equipo de # C ha publicado una guía de codificación que indica que vardebería solamente ser utilizado para capturar el resultado de una declaración de LINQ que crea un tipo anónimo (porque aquí, no tenemos ninguna alternativa real a var). Bueno, joder eso. Mientras el equipo de C # no me dé un argumento sólido para esta guía, voy a ignorarla 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 algunas (superficialmente) buenas explicaciones sobre por qué no deberías usarlas, varpero sigo creyendo que están equivocadas. Tomemos el ejemplo de "capacidad de búsqueda": el autor afirma que vardificulta la búsqueda de lugares donde MyTypese utiliza. Derecha. También 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 instancia y esto aún se podrá buscar porque en algún lugar se debe invocar a su constructor (incluso si esto se hace indirectamente, el nombre del tipo debe mencionarse en algún lugar).

Var, en mi opinión, en C # es algo bueno ^tm . Cualquier variable que se escriba de este modo todavía se escribe con fuerza, pero obtiene su tipo del lado derecho de la asignación donde se define. Debido a que la información de tipo está disponible en el lado derecho, en la mayoría de los casos, es innecesario y excesivamente detallado también tener que ingresarla en el lado izquierdo. Creo que esto aumenta significativamente la legibilidad sin disminuir la seguridad del tipo.

Desde mi perspectiva, usar buenas convenciones de nomenclatura para variables y métodos es más importante desde una perspectiva de legibilidad que la información de tipo explícito. Si necesito la información de tipo, siempre puedo pasar el mouse sobre la variable (en VS) y obtenerla. Sin embargo, en general, la información de tipo explícito no debería ser necesaria para el lector. Para el desarrollador, en VS todavía obtienes Intellisense, independientemente de cómo se declare la variable. Habiendo dicho todo eso, 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 desee tratarlo como unIEnumerable<T>en tu método Para asegurarse de que está utilizando la interfaz, declarar la variable del tipo de interfaz puede hacerlo 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 de tipo es útil o necesaria, continúe y úsela. Sin embargo, creo que normalmente no es necesario y el código es más fácil de leer sin él en la mayoría de los casos.

Ninguno de esos es absolutamente cierto; varpuede tener efectos positivos y negativos sobre la legibilidad. En mi opinión, vardebería usarse cuando cualquiera de los siguientes es cierto:

1. El tipo es anónimo (bueno, no tiene otra opción aquí, ya que debe ser var en este caso)
2. El tipo es obvio en función de la expresión asignada (es decir var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

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

De Eric Lippert, ingeniero sénior de diseño de software en el equipo de C #:

¿Por qué se varintrodujo 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 se ve obligado a escribir exactamente lo mismo dos veces, es una redundancia que podemos eliminar. Mucho mejor para escribir

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

y deje que el compilador descubra en qué tipo se basa la asignación.

En segundo lugar, C # 3.0 introduce tipos anónimos. Dado que los tipos anónimos, por definición, no tienen nombres, que necesita para ser capaz de inferir el tipo de la variable de la expresión de inicialización si su tipo es anónima.

El énfasis es mío. Todo el artículo, C # 3.0 todavía está estáticamente escrito, ¡honesto! , y las series que siguen son bastante buenas.

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

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

No tengo problemas para 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 alguien que lea el código sería mucho más probable que entienda qué es "lista". Si tiene control sobre el nombre de la variable de lista en sí, 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 a 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 yo (ab) uso var.

Hemos adoptado el "Código para personas, no para máquinas", basado en el supuesto de que usted pasa varias veces más tiempo en modo de mantenimiento que en un nuevo desarrollo.

Para mí, eso excluye 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 de su código, pero cuando el próximo desarrollador está leyendo el código dentro de 6 meses, deben poder deducir lo que la variable está haciendo correcta o incorrectamente e identificar rápidamente la causa de los problemas.

Así,

var something = SomeMethod();

está prohibido por nuestros estándares de codificación, pero se recomienda lo siguiente en nuestro equipo 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 cosa estilística, que tiende a ser subjetiva. Puede agregar inconsistencias, cuando usa var y cuando no lo hace.

Otro caso de preocupación, en la siguiente llamada, no se puede saber simplemente mirando el código del tipo devuelto por CallMe:

var variable = CallMe();

Esa es mi queja principal contra la var.

Uso var cuando declaro delegados anónimos en métodos, de alguna manera var se ve más limpio que si lo usara Func. Considera 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 es como una variante en absoluto. La variable todavía está fuertemente tipada, es solo que no presiona las teclas para obtenerla de esa manera. Puede pasar el mouse sobre él en Visual Studio para ver el tipo. Si está leyendo el código impreso, es posible que tenga que pensar un poco para averiguar cuál es el tipo. Pero solo hay una línea que lo declara y muchas líneas que lo usan, por lo que dar nombres decentes sigue siendo la mejor manera de hacer que su código sea más fácil de seguir.

¿Está usando Intellisense perezoso? Escribe menos que el nombre completo. ¿O hay cosas que son menos trabajo pero que no merecen críticas? Creo que los hay, y var es uno de ellos.

El tiempo más probable que necesitará esto es para los tipos anónimos (donde es 100% requerido); pero también evita la repetición de los casos triviales, y la OMI aclara la línea. No necesito ver el tipo dos veces para una simple inicialización.

Por ejemplo:

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

(por favor, no edite el hscroll en lo anterior, ¡¡¡esto prueba el punto !!!)

vs:

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

Sin embargo, hay ocasiones en que esto es engañoso y potencialmente puede causar errores. Tenga cuidado al usar varsi la variable original y el tipo inicializado no eran 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 puede confiar en mouse-over para eso.

No veo cuál es el gran 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? ( ¿Vos si? )

No es varchar, no es tenue, y ciertamente no es un tipeo dinámico o débil. Está deteniendo a los locos como este:

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

y reduciendo ese desorden mental total a:

var v = new List<somethinglongtypename>();

Agradable, no tan agradable como:

v = List<somethinglongtypename>();

Pero entonces para eso está Boo .

Si alguien está usando la varpalabra clave porque no quiere "descifrar el tipo", esa es definitivamente la razón incorrecta. La varpalabra 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 debería ser evidente en el código si es posible.

Las buenas razones para usar la varpalabra clave son, por ejemplo:

• Donde sea necesario, es decir, declarar una referencia para un tipo anónimo.
• Donde hace que el código sea más legible, es decir, elimina las 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 tiene que averiguar el tipo de datos descubriendo 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 se define fuera del área de la pantalla visible.

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 VAR es usarlo solo cuando sea apropiado, es decir, al hacer cosas en Linq que facilite (y probablemente en otros casos).

Si tiene un tipo para algo en el, entonces debe usarlo; no hacerlo es simple pereza (a diferencia de la pereza creativa que generalmente se fomenta), los buenos programadores a menudo trabajan muy duro para ser flojos y podrían considerarse la fuente de la cosa en primer lugar).

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

La otra cosa para recordar es que no es una variable 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 (es por eso que hay personas que argumentan que no es irrazonable lo uso en, por ejemplo, un foreach, pero no estoy de acuerdo por razones de legibilidad y mantenibilidad).

Sospecho que este va a correr y correr (-:

Murph

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

Robado de la publicación 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 habría sido hacer algo como lo siguiente:

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 sólo se va a alguna vez ser la persona que mira a su código, a continuación, 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();

Cortocircuita cualquier tipo de deducciones inmediatas que mi cerebro pueda comenzar a formar a partir del "inglés" del código.

De lo contrario, solo use su mejor criterio y programa 'cortesía' hacia otras personas que podrían tener que trabajar en su proyecto.

Usar en varlugar del tipo explícito hace que las refactorizaciones sean mucho más fáciles (por lo tanto, debo contradecir los carteles anteriores que significaban que no había diferencia o que era puramente "azúcar sintáctico").

Puede cambiar el tipo de retorno de sus métodos sin cambiar todos los archivos donde se llama a este método. Imagina

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

que se usa como

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

Si desea refactorizar SomeMethod()para devolver un IEnumerable<MySecondClass>, tendría que cambiar la declaración de variable (también dentro de 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 tienes que cambiarlo.

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

Básicamente no quiero ir a escribir con mi mouse. Puede que no esté disponible.

Es cuestión de gustos. Todo este alboroto sobre el tipo de variable desaparece cuando te acostumbras a los idiomas escritos dinámicamente. Es decir, si alguna vez comienza a gustarles (no estoy seguro de si todos pueden, pero a mí sí).

C # 's vares bastante bueno ya que parece una escritura dinámica, pero en realidad es una escritura estática : el compilador impone el uso correcto.

El tipo de su variable no es realmente tan importante (esto se ha dicho antes). Debe ser relativamente claro por el contexto (sus interacciones con otras variables y métodos) y su nombre: no espere que customerList contenga un int...

Todavía estoy esperando ver qué piensa mi jefe sobre este asunto: obtuve una "manta" para usar cualquier construcción nueva en 3.5, pero ¿qué haremos con respecto al mantenimiento?

En su 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 varque no es dinámica. Es solo magia de compilación y cualquier tipo de llamadas inseguras que hagas quedarán atrapadas.

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 anonEnumeration en intellisense y aparecerá algo así 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
}

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

Fuera de eso, siempre que tenga inteligencia, tiene sentido usar en varcualquier lugar donde el contexto sea 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 ninguna dificultad para entender un código debido al var"mal uso", y mis compañeros de trabajo y yo lo usamos bastante. (Estoy de acuerdo en que Intellisense es una gran ayuda en este sentido). Lo acojo con satisfacción como una forma de eliminar la ruina 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 fuera realmente imposible de tratar, nadie usaría lenguajes escritos dinámicamente.

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

Por ejemplo, usaría var en este caso, porque puede ver de inmediato que x será del tipo "MyClass":

var x = new MyClass();

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

var x = MyClass.MyFunction();

Especialmente, nunca uso var en los casos en que el lado derecho ni siquiera es 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 varilustra por qué el bilingüismo en .NET es importante. Para aquellos programadores de C # que también han hecho VB .NET, las ventajas de varson intuitivamente obvias. 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, 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)

Al igual que tendría que hacer en C #, y obviamente no podría usar varpara:

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

Si necesita que el tipo sea algo diferente, puede serlo. 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á allí. Cualquier otra cosa es un uso demasiado lejos. Como muchas personas que crecieron en C, estoy acostumbrado a mirar a la izquierda de la declaración para el tipo. No miro al lado derecho a menos que tenga que hacerlo. Usar varpara cualquier declaración antigua me hace hacerlo todo el tiempo, lo que personalmente me resulta incómodo.

Aquellos que dicen 'no importa, usa lo que te hace feliz' no están viendo la imagen completa. Todos recogerá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 todo ' varo no' a la mezcla. El peor de los casos será cuando un programador no usó vary luego viene un mantenedor que lo ama y extiende el código usándolo. Así que ahora tienes un lío impío.

Los estándares son algo bueno precisamente porque significan que es mucho más probable que pueda recoger código aleatorio y poder asimilarlo rápidamente. Cuantas más cosas sean diferentes, más difícil será. Y pasar al estilo 'var en todas partes' hace una gran diferencia.

No me importa la escritura dinámica, y no me importa la escritura implícita, en idiomas diseñados para ellos. Me gusta bastante Python. Pero C # fue diseñado como un lenguaje estáticamente tipado explícitamente y así es como debe permanecer. Romper las reglas para los tipos anónimos fue bastante malo; dejar que la gente lo lleve 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 está fuera de la botella, nunca volverá a entrar. C # será balcanizado en campamentos. No está bien.

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 del mismo tipo que devuelve CallMethod (). Sin embargo, como estoy usando var, solo 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 que varahorran tiempo, se necesitan menos pulsaciones de teclas para escribir:

StringBuilder sb = new StringBuilder();

que

var sb = new StringBuilder();

Cuenta si no me crees ...

19 contra 21

Explicaré si es necesario, pero solo pruébalo ... (dependiendo del estado actual de tu inteligencia, es posible que tengas que escribir un par más para cada uno)

¡Y es cierto para cada tipo que se te ocurra!

Mi sensación personal es que nunca se debe usar var, excepto donde no se conoce el tipo porque reduce la legibilidad de reconocimiento en el código. El cerebro tarda más en reconocer el tipo que una línea completa. Los veteranos que entienden el código de máquina y los bits saben exactamente de lo que 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 trabaje más? Para eso están las computadoras.

Divido var por todos los lugares, los únicos lugares cuestionables para mí son los tipos cortos internos, por ejemplo, prefiero int i = 3;sobrevar i = 3;

Ciertamente puede simplificar las cosas, del 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.

Anexo: Un poco de tiempo dedicado a un lenguaje con inferencia de tipo real (por ejemplo, F #) mostrará cuán buenos son los compiladores para obtener el tipo correcto de expresiones. Ciertamente ha significado que tiendo a usar vartodo lo que puedo, y usar un tipo explícito ahora indica que la variable no es del tipo de expresión inicializadora.

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