Uso de la palabra clave var en C#

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 mantiene 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 se pasa involuntariamente el tipo incorrecto a un método.

Sep 03 '08 18:09 ljs

Lo uso varmucho. 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, enfáticamente no le interesa el tipo que tiene una variable. varlleva esto 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 debería estar interesado en el tipo de variable sino en lo que hace una variable . 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 una varvariable declarada y me confundo para qué sirve la variable, hay algo fundamentalmente incorrecto en mi código. varno 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 solovar debe usarse para capturar el resultado de una declaración LINQ que crea un tipo anónimo (porque aquí no tenemos una alternativa real a ). 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).var

En realidad, hay algunas explicaciones (superficialmente) buenas sobre por qué no deberías usarlo var, pero sigo creyendo que son en gran medida erróneas. Tomemos el ejemplo de la “capacidad de búsqueda”: el autor afirma que vardificulta la búsqueda de lugares donde MyTypese 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).

Sep 03 '2008 12:09

Var, en mi opinión, en C# es ^algo bueno . 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, aún puede haber casos en los que tenga sentido declarar explícitamente el tipo; tal vez tenga un método que devuelva a List<T>, pero quiera tratarlo como un IEnumerable<T>en su 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.

May 19 '2010 13:05 tvanfosson