Uso de variables locales escritas implícitamente [duplicado]

Question

    

Esta pregunta ya tiene una respuesta aquí:

    

        
•              ¿Por qué var sería algo malo?                                      17 respuestas                          
    

    

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

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

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

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

Answer 1

Yo personalmente solo uso & # 8220; var & # 8221; 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 & # 8220; var & # 8221; se refiere a & # 8220; List < int > & # 8221 ;.

No & # 8217; no me gusta usar & # 8220; var & # 8221; cuando tengo que ir a alguna definición de método para averiguar qué tipo de variable & # 8220; var & # 8221; representa o al tener que confiar en Visual Studio Intelli-Popup o como se llame, por ejemplo, esto no está bien para mí:

var someVaraible = SomeMethod();

Quiero decir, ¿cuál es el & # 8220; SomeMethod & # 8221; función se supone que debe volver? ¿Puedes decirlo simplemente mirando la línea de código? No, no puedes & # 8217; t, por eso evito usar & # 8220; var & # 8221; en esas situaciones.

Answer 2

Hay mucha discusión sobre esto, pero creo que todo se reduce a un gusto personal, al igual que usar la palabra clave 'this' en casi todas partes.

Yo personalmente prefiero las variables tipadas explícitamente, pero cuando se usan colecciones genéricas anidadas, las cosas pueden volverse más legibles usando una variable tipeada implícitamente. Mira:

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 tipo de nombre de objeto?

EDIT2: Trabajando mucho con asíncrono hoy en día, encuentro que el uso de variables escritas explícitamente a veces puede prevenir errores desagradables. Considere este ejemplo tonto en el que desea devolver el Id. De un usuario. También considere que GetUserAsync devuelve un Task<User>. Si usa variables escritas 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 un Task. Y se compila como Id también tiene una propiedad await. 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 se compila, ya que el compilador se quejará de que no puede enviar una Tarea a un Usuario. Agregar la palabra clave <=>, por supuesto, resuelve esto.

Realmente me ha pasado esto una vez :-)

Answer 3

En caso de que algunos no hayan & # 8217; todavía no se ha notado, puede cambiar fácilmente las & # 8220; sugerencias & # 8221; en Reshaper (Reshaper - > Opciones - > Idiomas - > Acciones de contexto - > & # 8220; Reemplace la especificación de tipo explícito con & # 8216; var & # 8217; & # 8221;).

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

Answer 4

Es más fácil escribir la pseudo-palabra clave var a veces que un nombre de tipo enorme, especialmente si podría estar involucrado un genérico. Sin embargo, debe 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 sucede en tiempo de ejecución como una variante de VB.

Answer 5

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

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

   var map = new Dictionary > ();

2. Las variables locales tienen buenos nombres.

HTH