usar - Uso de la palabra clave var en C#
que es float en programacion (30)
Después de conversar con colegas sobre el uso de la palabra clave ''var'' en C # 3, me pregunté qué opinión tenía la gente sobre los usos apropiados de la inferencia de tipos a través de var.
Por ejemplo, utilicé la varilidad 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 un poco 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 implementa 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 para objetos, por ejemplo:
var results = from item in someList
where item != 3
select item;
Esto no es mejor que el equivalente foreach (var item en someList) {// ...} equivilent.
Existe una preocupación real sobre la seguridad de los tipos aquí: por ejemplo, si colocáramos los resultados de esa consulta en un método sobrecargado que aceptara IEnumerable <int> e IEnumerable <double>, la persona que llama podría pasar inadvertidamente el tipo equivocado.
var mantiene una tipificación fuerte, pero la pregunta es si realmente es peligroso que el tipo no se vea inmediatamente en la definición, algo que se magnifica cuando las sobrecargas significan que los errores del compilador no se pueden emitir cuando involuntariamente se pasa el tipo incorrecto a un método.
Claro, int es fácil, pero cuando el tipo de la variable es IEnumerable<MyStupidLongNamedGenericClass<int, string>> , var hace las cosas mucho más fáciles.
Creo que el uso de var debería ir acompañado de nombres de variables elegidos sabiamente.
No tengo problemas para usar var en una sentencia 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 lea el código entienda qué es la "lista". Si tiene control sobre el nombre de la variable de la lista, eso es aún mejor.
Lo mismo se puede aplicar 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 he encontrado 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.
Creo que la clave con VAR es usarlo solo cuando sea apropiado, es decir, al hacer cosas en Linq que facilita (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 recomienda), los buenos programadores a menudo trabajan muy duro para ser perezosos y podrían ser considerados 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 a recordar es que no es una var de tipo VB en que no puede cambiar los tipos; es una variable fuertemente tipada, solo que se infiere el tipo (por lo que hay personas que argumentarán que no es irrazonable). utilícelo en, digamos, un foreach pero no estoy de acuerdo por razones tanto de legibilidad como de mantenibilidad).
Sospecho que este va a correr y correr (-:
Murph
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 definen 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>();
De Eric Lippert, un ingeniero de diseño de software senior en el equipo de C #:
¿Por qué se introdujo la palabra clave var ?
Hay dos razones, una que existe en la actualidad, 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 cosas peores. Cada vez que te veas 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 determine qué tipo de letra se basa en la asignación.
En segundo lugar, C # 3.0 introduce tipos anónimos. Como los tipos anónimos por definición no tienen nombres, debe poder inferir el tipo de la variable de la expresión de inicialización si su tipo es anónimo.
Énfasis mío. ¡Todo el artículo, C # 3.0 todavía está tipificado estáticamente, honesto! , y las series siguen son bastante buenas.
Esto es para lo que es var . Otros usos probablemente no funcionarán tan bien. Cualquier comparación con JScript, VBScript o escritura dinámica es total de bunk. Tenga en cuenta nuevamente que se requiere var para que ciertas otras funciones funcionen en .NET.
El tiempo más probable que necesitará es para los tipos anónimos (donde se requiere el 100%); 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 la parte de arriba, ¡¡¡es un poco el punto !!!
vs:
var data = new Dictionary<string, List<SomeComplexType<int>>>();
Sin embargo, hay ocasiones en que esto es engañoso y puede causar errores. Tenga cuidado al usar var si 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);
Hemos adoptado el "Código para personas, no máquinas", basado en el supuesto de que usted gasta varias veces más tiempo en el modo de mantenimiento que en el nuevo desarrollo.
Para mí, eso descarta el argumento de que el compilador "sabe" de qué tipo es la variable; por supuesto, 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 está leyendo el código en 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 en nuestro equipo se recomienda lo siguiente porque aumenta la legibilidad:
var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
DoWork( item );
}
Ninguno de los dos es absolutamente cierto; var puede tener efectos tanto positivos como negativos en la legibilidad. En mi opinión, var debería usarse cuando cualquiera de las siguientes afirmaciones sea cierta:
- El tipo es anónimo (bueno, no tiene ninguna opción aquí, ya que debe ser var en este caso)
- El tipo es obvio basado en la expresión asignada (es decir,
var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())
var no tiene impacto en el rendimiento, ya que es azúcar sintáctica; el compilador infiere el tipo y lo define una vez que se compila en IL; No hay nada realmente dinámico al respecto.
No está mal, es más una cosa estilística, que tiende a ser subjetiva. Puede agregar inconsistencias, cuando usas var y cuando no.
Otro motivo de preocupación, en la siguiente llamada, no puede saberlo simplemente mirando el código del tipo devuelto por CallMe :
var variable = CallMe();
Esa es mi principal queja contra la var.
Utilizo var cuando declaro delegados anónimos en métodos, de alguna manera var luce 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
No veo cuál es el gran problema ...
var something = someMethod(); // Type of ''something'' not clear <-- not to the compiler!
Todavía tiene plena inteligencia sobre "algo", y para cualquier caso ambiguo tiene sus pruebas de unidad, ¿verdad? ( ¿Vos si? )
No es varchar, no es tenue, y ciertamente no es una tipificación dinámica o débil. Se está deteniendo a los maddnes así:
List<somethinglongtypename> v = new List<somethinglongtypename>();
y reduciendo ese recorte mental total a:
var v = new List<somethinglongtypename>();
Agradable, no tan bonito como
v = List<somethinglongtypename>();
Pero entonces para eso está Boo .
Si alguien está usando la palabra clave var porque no quieren "averiguar el tipo", esa es definitivamente la razón equivocada. La palabra clave var no crea una variable con un tipo dinámico, el compilador todavía tiene que saber 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.
Buenas razones para usar la palabra clave var 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, 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 tiene que averiguar el tipo de datos al averiguar qué hace el código.
Todavía creo que var puede hacer que el código sea más legible en algunos casos. Si tengo una clase de Cliente con una propiedad de Pedidos y quiero asignarla a una variable, solo 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 conteo 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 Customer.Orders por el camino (por ejemplo, desde ObservableCollection<Order> a IList<Order> ), también tengo que cambiar esa declaración, algo que no tendría que hacer si Yo había usado var en primer lugar.
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 los mouse-over para eso.
Var no es como variante en absoluto. La variable aún está fuertemente tipada, es solo que no presionas las teclas para hacerlo de esa manera. Puede desplazarse 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á utilizando Intellisense lazy? Es menos tipeo que el nombre completo. ¿O hay cosas que son menos trabajo pero que no merecen crítica? Creo que hay, y var es uno de ellos.
Var, en mi opinión, en C # es una buena cosa tm . Cualquier variable así escrita sigue siendo fuertemente tipada, pero obtiene su tipo desde el lado derecho de la tarea 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 verboso tener que ingresarla también 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ícita. Si necesito la información de tipo, siempre puedo desplazarme sobre la variable (en VS) y obtenerla. En general, sin embargo, la información de tipo explícita no debería ser necesaria para el lector. Para el desarrollador, en VS todavía obtienes Intellisense, independientemente de cómo se declara la variable. 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 una 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 hacerlo explícito. O, tal vez, desea declarar una variable sin un valor inicial, porque de inmediato 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 que el código es más fácil de leer sin él en la mayoría de los casos.
Yo uso var ampliamente. Se ha criticado que esto disminuye la legibilidad del código, pero ningún argumento para respaldar esa afirmación.
Es cierto que puede significar que no está claro de qué tipo estamos tratando. ¿Y qué? Este es realmente el punto de un diseño desacoplado. Cuando se trata de interfaces, no está interesado en el tipo que tiene una variable. var lleva 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 realmente interesado en el tipo de variable sino en lo que hace una variable. Esta es la razón por la que Microsoft también llama inferencia de tipo "escritura de pato".
Entonces, ¿qué hace una variable cuando la declaro usando var ? Fácil, hace lo que IntelliSense me dice que hace. Cualquier razonamiento sobre C # que ignore el IDE no llega a ser realidad. En la práctica, cada código C # está programado en un IDE que admite IntelliSense.
Si estoy usando una variable declarada var y me confundo para qué sirve la variable, hay algo fundamentalmente incorrecto en mi código. var no 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 var solo 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 var ). Bueno, enrosca eso. Mientras el equipo de C # no me dé un argumento sólido para esta guía, lo ignoraré porque, en mi opinión personal y profesional, es una tontería. (Lo siento; no tengo ningún enlace a la guía en cuestión).
En realidad, hay algunas explicaciones (superficialmente) buenas sobre por qué no debería usar var pero aún creo que están muy equivocadas. Tome el ejemplo de "searchabililty": el autor afirma que var hace que sea difícil buscar lugares donde se usa MyType . Derecha. Igual que las interfaces. En realidad, ¿por qué querría saber dónde se usa la clase? Puede que esté más interesado en dónde se crea una instancia y esto aún podrá buscarse porque en algún lugar se debe invocar a su constructor (incluso si esto se hace de manera indirecta, el nombre del tipo debe mencionarse en alguna parte).
Ciertamente puede hacer las cosas más simples, a partir 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 él 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 entender correctamente el tipo de expresiones. Ciertamente ha significado que tiendo a usar vartanto como puedo, y usar un tipo explícito ahora indica que la variable no es del tipo de expresión de inicialización.
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 lo que contiene SomeOtherThing, SomeOtherThing no es el mismo tipo que devuelve CallMethod (). Ya que estoy usando var, solo cambio esto:
var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
a esto:
var something = myObject.SomeProperty.SomeOtherThing;
Sin var, tendría que seguir cambiando el tipo declarado en el lado izquierdo también. Sé que es menor, pero es extremadamente conveniente.
Sólo uso var cuando está claro para ver qué tipo se utiliza.
Por ejemplo, usaría var en este caso, porque puedes ver inmediatamente 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 devuelve MyFunction:
var x = MyClass.MyFunction();
Especialmente, nunca uso var en los casos en que el lado derecho no es ni siquiera 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)
Úsalo para tipos anónimos, para eso está. 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 hacia el lado derecho a menos que tenga que hacerlo. Usar varpara cualquier declaración antigua me hace hacer eso todo el tiempo, lo que personalmente me parece incómodo.
Aquellos que dicen "no importa, usen aquello con lo que están contentos" no ven 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 (los típicos reclamos) los estilos de arriostramiento, sin agregar la varcosa '' o no'' completa a la mezcla. El peor de los casos será cuando un programador no usó vary luego aparece un mantenedor que lo ama y extiende el código al usarlo. Así que ahora tienes un lío impío.
Los estándares son una buena cosa precisamente porque significan que es mucho más probable que pueda captar un 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 lenguajes diseñados para ellos. Me gusta bastante Python. Pero C # fue diseñado como un lenguaje tipificado de forma estática y así debe ser. Romper las reglas para tipos anónimos era suficientemente malo; Permitir que la gente lo lleve aún más lejos y romper los modismos del lenguaje aún más es algo con lo que no estoy contento. Ahora que el genio está fuera de la botella, nunca volverá a entrar. C # se convertirá en balcanes en los campamentos. No está bien.
@aku: Un ejemplo son las revisiones de código. Otro ejemplo son los escenarios de refactorización.
Básicamente no quiero ir a la caza de tipos con mi ratón. Puede que no esté disponible.
Dividí var en todos los lugares, los únicos lugares cuestionables para mí son tipos cortos internos, por ejemplo, prefiero int i = 3;más quevar i = 3;
El uso en varlugar del tipo explícito hace que las refactorizaciones sean mucho más fáciles (por lo tanto, debo contradecir a los carteles anteriores que hicieron que no hiciera ninguna diferencia o era puramente "azúcar sintáctica")
Puede cambiar el tipo de retorno de sus métodos sin cambiar cada archivo al que se llama 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 quisiera 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 usó 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.
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ámico. Es solo la magia del compilador y cualquier tipo de llamadas inseguras que hagas será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 generados por separado tendrán el mismo tipo generado si sus propiedades coinciden.
Fuera de eso, siempre que tenga inteligencia, tiene sentido utilizar varel contexto en cualquier lugar.
//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;
Es cuestión de gustos. Todo este alboroto sobre el tipo de variable desaparece cuando te acostumbras a los idiomas tipeados dinámicamente. Es decir, si alguna vez te empiezan a gustar (no estoy seguro de que todos puedan, pero lo hago).
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 en el contexto (sus interacciones con otras variables y métodos) y su nombre. No espere que la lista de clientes contenga un int...
Todavía estoy esperando a ver qué piensa mi jefe de este asunto. Tengo una manta "adelante" para usar cualquier construcción nueva en 3.5, pero ¿qué haremos con el mantenimiento?
Ninguna, excepto que no tiene que escribir el nombre de tipo dos veces. http://msdn.microsoft.com/en-us/library/bb383973.aspx
Para los aficionados que piensan que varahorra tiempo, se necesitan menos pulsaciones para escribir:
StringBuilder sb = new StringBuilder();
que
var sb = new StringBuilder();
Cuéntalos si no me crees ...
19 contra 21
Explicaré si tengo que hacerlo, pero solo inténtelo ... (dependiendo del estado actual de su inteligencia, puede que tenga que escribir un par más para cada uno)
¡Y es cierto para todos los tipos que puedas imaginar!
Mi opinión personal es que nunca se debe usar var, excepto cuando no se conoce el tipo porque reduce el legibilidad del reconocimiento en el código. Al cerebro le lleva más tiempo reconocer el tipo que una línea completa. Los antiguos 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 duro? Para eso son las computadoras.
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 e inicializa todo en una línea razonablemente compacta. Ah, pero ¿y si quieres una IList<string>, no una 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ías que hacer en C #, y obviamente no se podría usar varpara:
IList<string> whatever = new List<string>();
Si necesitas 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.
Robado de la publicación sobre este tema en CodingHorror :
Desafortunadamente, usted y todos los demás prácticamente 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 lo siguiente:
MyObject m = new ();
O si estás pasando parámetros:
Persona p = nuevo ("Nombre", "Apellido");
Donde en la creación de un nuevo objeto, el compilador infiere el tipo desde el lado izquierdo, y no el 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é aquí).
Al final, no estaba destinado a reducir la redundancia. No me malinterpretes, "var" es MUY importante en C # para tipos / proyecciones anónimas, pero el uso aquí es APAGADO (y lo he estado diciendo por mucho, mucho tiempo) mientras ofuscas el tipo que esta siendo usado. Tener que escribirlo dos veces es demasiado frecuente, pero declararlo cero veces es demasiado poco.
Nicholas Paldino .NET / C # MVP el 20 de junio de 2008 08:00 AM
Supongo que si su principal preocupación es tener que escribir menos, entonces no hay ningún argumento que le impida utilizarlo.
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 juicio y programación ''cortesía'' hacia otras personas que podrían tener que trabajar en su proyecto.
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 por todas partes. (Estoy de acuerdo en que Intellisense es una gran ayuda en este sentido). Lo celebro como una forma de eliminar el repetitivo cruft.
Después de todo, si las 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 tratar, nadie usaría lenguajes tipificados dinámicamente.