c# - tipo - Usar variables locales tipadas implícitamente

las variables locales con tipo implícito se deben inicializar

Question

Esta pregunta ya tiene una respuesta aquí:

• ¿Por qué var sería una mala cosa? 17 respuestas

Acabo de instalar una versión de prueba de ReSharper y una de las primeras cosas que noté es que siempre sugiere reemplazar las variables locales explícitamente tipadas por las implícitamente tipadas, por ejemplo:

public string SomeMethod(int aParam)
{
int aNumber = SomeOtherMethod(aParam);
// should be changed to:
var aNumber = SomeOtherMethod(aParam);
}

Creo que las variables explícitamente tipadas son más legibles (más explícitas).

¿Qué piensas de la sugerencia de ReSharper? ¿Hay alguna ventaja en el uso de variables tipadas implícitamente? ¿Cuándo usas los vars implícitos / explícitos?

Answer 1

En caso de que algunos no lo hayan notado aún, puede cambiar fácilmente las "sugerencias" en Reshaper (Reshaper -> Opciones -> Idiomas -> Acciones de contexto -> "Reemplazar la especificación de tipo explícita con ''var''").

Personalmente, prefiero tener especificaciones de tipo explícito en todas partes, pero no soy demasiado exigente al respecto.

Answer 2

FWIW, la palabra clave var es claramente legible en muchos casos. Especialmente si...

1. El lado derecho de la tarea es una expresión de constructor.

   var map = new Dictionary> ();

2. Las variables locales tienen buenos nombres.

HTH

Answer 3

Hay mucha discusión sobre esto, pero creo que todo se reduce al gusto personal, al igual que el uso de la palabra clave "esto" en casi todas partes.

Personalmente, prefiero las variables explícitamente tipadas, pero al usar colecciones genéricas anidadas, las cosas pueden volverse más legibles usando una variable implícitamente tipada. Mirar:

Dictionary<string, Dictionary<string, string>> myDictionary = new Dictionary<string, Dictionary<string, string>>();

vs:

var myDictionary = new Dictionary<string, Dictionary<string, string>>();

EDITAR: este tema SO cubre el mismo tema, con algunas buenas respuestas: ¿Qué usar: var o nombre del objeto?

EDIT2: Trabajando mucho con async hoy en día, encuentro que el uso de variables explicity mecanografiadas a veces puede prevenir errores desagradables. Considere este ejemplo tonto en el que le gustaría devolver el Id de un usuario. También considere que GetUserAsync devuelve una Task<User> . Si usa variables tipadas implícitamente, terminaría usando algo como esto:

public long GetUserId()
{
var user = GetUserAsync();
return user.Id;
}

Esto compila, pero está mal. ''usuario'' es en realidad una Task<User> . Y se compila ya que Task también tiene una propiedad Id . En este caso, uno devolvería accidentalmente el ID de una tarea en lugar del usuario.

public long GetUserId()
{
User user = GetUserAsync();
return user.Id;
}

Lo anterior no compila, ya que el compilador se quejará de que no puede enviar una tarea a un usuario. Agregar la palabra clave await por supuesto resuelve esto.

De hecho, me sucedió esto una vez :-)

Answer 4

Personalmente, solo uso "var" cuando puedo distinguir claramente la variable Tipo simplemente leyendo la declaración, por ejemplo:

var someVariable = new List<int>();

En el ejemplo anterior, es evidente que "var" se refiere a "List <int>".

No me gusta usar "var" cuando tengo que ir a alguna definición de método para averiguar qué tipo de variable "var" representa o al tener que depender de visual studio intelli-popup o lo que se llame, por ejemplo, esto en no está bien para mí:

var someVaraible = SomeMethod();

Quiero decir, ¿qué se supone que devuelve la función "SomeMethod"? ¿Puedes decir solo mirando la línea de código? No, no puedes, así que es por eso que evito usar "var" en esas situaciones.

Answer 5

Simplemente es más fácil escribir var pseudo-keyword a veces que un nombre de tipo enorme, especialmente si se trata de un genérico. Sin embargo, debes saber que son funcionalmente idénticos. No hay diferencia de rendimiento ni nada de ninguna manera. El compilador deriva el tipo del lado derecho de la asignación y reemplaza var con ese tipo. No está sucediendo en tiempo de ejecución como una variante de VB.