Más allá del uso evidente de var con LINQ, yo también lo uso para abreviar las declaraciones de variables peludas para facilitar la lectura, por ejemplo:
var d = new Dictionary<string, Dictionary<string, Queue<SomeClass>>>();
En general, me sale una especie de comodidad (a falta de una palabra mejor) de mecanografía estática que me hace reacio a renunciar a ella. Me gusta la sensación de que sé lo que estoy haciendo cuando declaro una variable. Declarar una variable no es solo decirle al compilador algo, sino decirle a la persona que lee algo sobre su código.
Déjeme darle un ejemplo. Supongamos que tengo un método que devuelve un List<string>. Este código es ciertamente correcto, y creo que es como el 90% de los desarrolladores de C#, probablemente escribirlo:
List<string> list = MyMethod();
Obviamente, ¿verdad? De hecho, aquí hay un lugar donde puedes usar var.
Es cierto. Pero esta versión del código no se acaba de declarar una variable, que me está diciendo lo que la persona que lo escribió tiene la intención de hacer:
IEnumerable<string> list = MyMethod();
El desarrollador que escribió el código me está diciendo "Soy no voy a cambiar esta lista, ni voy a usar un índice para acceder a sus miembros. Todo lo que voy a hacer es repetirlo ". Esa es una gran cantidad de información para transmitir en una sola línea de código. Es algo a lo que renunciar si usa var.
Por supuesto, no lo va a dejar si no lo estaba usando en primer lugar. Si usted es el tipo de desarrollador que escribiría esa línea de código, ya sabe que no usaría var allí.
Editar:
Me acabo de releer el post de Jon Skeet, y esta cita de Eric Lippert me llamó la atención:
locales Implícitamente se escriben sólo una pequeña forma en que se puede quitar importancia a la cómo y por lo tanto enfatizar el qué.
Creo que en realidad en muchos casos el uso de tipeo implícito es lo que implícito. Está bien no pensar en el qué. Por ejemplo, voy a escribir casualmente una consulta LINQ como:
var rows = from DataRow r in parentRow.GetChildRows(myRelation)
where r.Field<bool>("Flag")
orderby r.Field<int>("SortKey")
select r;
Cuando leí ese código, una de las cosas que pienso cuando estoy leyendo es "rows es un IEnumerable<DataRow>."Porque sé que lo que LINQ consulta de retorno es IEnumerable<T>, y puedo ver el tipo del objeto que se ha seleccionado allí mismo.
Eso es un caso en el que lo no ha ha hecho explícito. Se ha dejado para mí .. para inferir
Ahora, en alrededor del 90% de los casos en los que uso de LINQ, esto no importa un poquito porque el 90% de las veces, la siguiente línea de código es:
foreach (DataRow r in rows)
Pero no es difícil imaginar un código en el que sería muy útil declarar rows como IEnumerable<DataRow> - código donde se consultaban muchos tipos diferentes de objetos, no era factible colocar la declaración de consulta al lado de la iteración, y sería útil poder inspeccionar rows con IntelliSense. Y eso es una cosa, no una cuestión de cómo.
Gran pregunta. – Contango