.Net 3.0: ¿Vale la pena usar la palabra reservada var?

Ya hace tiempo cuando estuve trabajando con LINQ en una de las empresas que estuve, mi jefe me explicó las ventajas de usar la palabra reservada "var", que aunque no es algo así como muy milagroso, si vale la pena mencionar sus ventajas, muy pocas ventajas, pero que si me parecen muy interesantes!.

Como todos bien saben, o si no lo sabían, en .Net todas las variables deben ser fuertemente tipificadas; es decir, tenemos que especificar de qué tipo será la variable, por ejemplo: int, short, long, un tipo definido por el usuario, etc.

Ahora bien, con la entrada de la versión de .Net 3.0 aparece la palabra reservada "var" con la cual podemos declarar variables en forma implícita; esto significa que no es necesario que especifiquemos el tipo de la variable, dejando ese trabajo al compilador.

Muchos programadores pensarían que eso es una "mala práctica de programación" porque estamos forzando más trabajo para el compilador y que el producto final que se instala en producción no será eficiente, etc.

Si siguen leyendo está entrada se darán cuenta que NO ES CIERTO tal afirmación, usar var es algo normal, jaja!.

1º) Originalmente "var" se creó para utilizarlo con los tipos anónimos, que hablando de temas de LINQ se hace muy claro la existencia de "var".

2º) var se puede utilizar en cualquier código que queramos hacer, con las siguientes excepciones:

a)- Al declarar una variable implícita, siempre debemos asignarle un valor; es decir, no podemos poner:

var resultado;

Lo anterior no funciona porque el compilador no va a poder definir de que tipo debe ser la variable.

b) var, solo se puede usar dentro de métodos de una clase.

c) No es posible retonar un tipo var y los parámetros tampoco pueden ser var; es decir, si queremos definir una función tal como:

public var Cuadrado(var base){
      return base*base;
}

Lo anterior no funciona!


Ahora, las ventajas:

1º) No tenemos que estar escribiendo el tipo de la variable y ni siquiera el namespace reduciendo la línea de código en gran medida.:

     var resultado = gridDatos.ItemsSource as List<Productos>;

En el ejemplo anterior se usa la clase List genérica con el tipo Productos, donde Productos es una clase definida por el usuario. La línea de código anterior sin usar var quedaría así:

ObservableCollection<Productos> resultado = gridDatos.ItemsSource as ObservableCollection<Productos>;

Notar como se está especificando en el ejemplo anterior, el tipo en ambos lados, lo cual es entendible pero innecesario, en lo personal, ahora que conozco la existencia de var.

Ahora consideren cuando el programador gusta poner el nombre de namespace completo (sin usar alias), la línea de código quedaría extremadamente larga. Además por si no lo sabían, el optimizador del compilador quita los namespace largos y los combierte en alias o simplemente los quita y deja solo el nombre del tipo exacto sin especificar todas las partes del namespace.

2º) Como mencioné anteriormente, muchos programadores piensan que usar var no es eficiente para el producto final que entregamos al cliente; está afirmación es falsa, porque el compilador se encarga de inferir los tipos de datos donde existe var generando un ensamblado en donde reemplaza las palabras var por el tipo que se le está asignando a la variable. Es decir, los ensamblados generados son iguales si nosotros declaramos explícitamente o implícitamente las variables.

Veamos éste sencillo ejemplo donde se declara una variable usando var.

Ahora vean el código des-ensamblado, donde se observa que el compilador dedujo el tipo de datos, en éste caso es int.

Igualmente en el código MSIL (Microsoft Intermediate Language) tenemos que el tipo de datos para la variable "i" es int:

Por cierto en Visual Basic .Net, el equivalente de var es la palabra reservada Dim, por ejemplo: Dim miVariable = 5 * 5.

Referencia:

El excelente libro que leí hace mucho tiempo: LINQ IN ACTION de Fabrice Marguerie, Steve Eichert y Jim Wooley.