¿Por que usar los tipos de datos de .NET Framework?

Leyendo un poco en la Web, sobre todo sobre C#, es común encontrar a quien recomienda como buena práctica de programación, utilizar las palabras claves propias del lenguaje para los tipos de datos, en vez de utilizar las clases del Framework. No estoy de acuerdo con esto, no tanto con el enunciado, si no en clasificarlo como “buena práctica”.

Utilizar una u otra nomenclatura es indiferente para la ejecución del código, ya que los tipos de datos del lenguaje, tanto VB como C# son solo shorcuts a los tipos de nativos de .NET. Veamos que hay a favor y en contra de utilizar los tipos del framework:

• (+) Es particularmente útil para quienes programamos en ambos lenguajes, por más asimilados que tengamos o no ambas sintaxis, siempre es más fácil utilizar la misma en ambos lenguajes, y aunque se utilize uno solo, será más facil para nosotros cuando tengamos que aprender el otro. También hay que considerar que no sabemos que background tendrá quien lea nuestro código en el futuro.
• (+) El Visual Studio 2005+ resalta (solo C#) en un feo color ¿turquesa? los tipos de datos del framework, diferenciándolos del resto de las palabras claves.
• (+) La sintaxis será soportada en futuros lenguajes .NET
• (-) Hay que incluir un Imports/using del namespace System (aunque Visual Studio lo incluye en la mayoría, si no en todos los documentos.)
• (-) Quienes venimos de otros lenguajes ya tenemos una sintaxis incorporada.
• (-) Personas provenientes de otros lenguajes, particularmente C++, pueden ver afectada su virilidad.

Como vemos no hay razones de peso para utilizar uno u otro estándar, pocas para hacer una recomendación y creo que ninguna para calificar de “buena práctica” una u otra nomenclatura por sobre otra.

Para completar, algunos tips que no siempre se tienen presente y una tabla comparativa entre los dos lenguajes y el framework:

• Short es más lento que integer, aunque pueda ocupar menos memoria.
• Interger es el tipo numérico más eficiente en términos de rendimiento.
• Los enteros sin signo (UInt16/32/64) son igualmente rápidos que los signados y con mayor capacidad, siempre que se sepa que solo se almacenaran enteros positivos, pero no son cls compliant.
• Decimal” es el tipo con mayor rango pero las operaciones con este tipo son mucho más lentas que con el resto
  Double es el tipo real más rapido (en plataformas de 32 bits)
• A partir del framework 3.5, existe una nueva estructura para albergar fechas y horas: DataTimeOffset, que maneja zonas UTC. Si bien sigue existiendo DateTime, DateTimeOffset será la recomendación de Microsoft.

Tabla comparativa

VB.NET	C# .NET	.NET Framework	Almacenamiento	Intervalo
Boolean	bool	Boolean	-	true/false
Byte	byte	Byte	1 byte	[0;255]
Short	short	Int16	2 bytes	[-32768;32767]
Integer	int	Int32	4 bytes	[-2147483648;2147483647]
Long	long	Int64	8 bytes	[-10E19;10E19]*
Single	float	Single	4 bytes	[-10E38;10E38]*
Double	double	Double	8 bytes	[-10E308;10E308]*
Decimal	decimal	Decimal	12 bytes (parte entera)	[-10E28;10E28]*
Date	System.DateTime	DateTime	8 bytes	[1/1/0001;31/12/9999]
String	string	String	-	-
Char	char	Char	2 bytes	-
Object	object	Object	4bytes (32 bits) / 8 bytes (64 bits)	-
SByte	sbyte	Sbyte	1 byte	[-128/127]
UShort	ushort	UInt16	2 bytes	[0:65535]
UInteger	uint	UInt32	4 bytes	[0;4.294.967.295]
ULong	ulong	UInt64	8 bytes	[0;1,8E19]

* datos apróximados.

Saludos.

Operador ternario en c# y vb…y ??

Algo creo que muy util de C# y que no existía en VB es el operador ternario, bueno en VB existe el IIf, pero hay una gran diferencia. Veamos:

En C#, la manera de utilizar el operador ternario es la siguiente

result = condición_lógica ? valor_si_verdadero : valor_si_falso;

Por ej.:

Int32 mayor = (a > b) ? a : b;

(los paréntesis no son necesarios, solo para legibilidad)

En este ejemplo clásico para devolver el mayor valor, si la condición lógica es verdadera ‘mayor’ valdrá a, caso contrario se le asignará b.

Ahora, que pasa si quiero utilizar el operador ‘?’ para lo siguiente:

String _usuario = (usuario != null) ? usuario : "invitado";

Bien, funciona, pero aquí puedo utilizar el operador ?? de C#, (o null coalescing operator) y obtener el mismo resultado con esta sentecia:

String _usuario = usuario ?? "invitado";

Este operador retorna el operando de la izquierda excepto cuando es nulo, donde retorna el de la derecha ‘invitado’ (ojo, no sirve para una cadena vacía, solo null)

Operador ternario en VB

A priori parecería que se puede utilizar el método IIf en VB como operador ternario, volviendo al primer ejemplo algo así como:

Dim mayor as Int32 = IIf(a > b, a, b)

¿funciona igual esto? sssNO. IIf es una función, por lo tanto retorna un tipo, ¿cual? Object. Y ahí se acabaron para mi todas la razones para utilizar IIf, ya que para no tener problemas y evitar casteos implicitos (una de las ‘licencias’ de VB que se aleja de la buena programación) tendríamos que convertir (CInt, CType…) el resultado antes de asignarlo a ‘mayor’.

Para colmo de males, como IIf es un método, todos los parámetros que se le pasan son evaluados previamente a la ejecución, por lo que se determinará el valor los dos posibles resultados sin importar cual sea el que retorne, más graficamente:

IIf(true, EstoSeEjecuta(), EstoYoNoQuisieraPeroSeEjecutaIgual())

Curioso: Si pasamos el código de C# a VB utilizando Reflector el operador ternario se refleja como IIf. Definitivamente Lutz sabe más que yo, pero creo que es una cuestión de legibilidad más que de exactitud.

En la MSDN David M. Kean propone hacer una función genérica, pero ¿que gracia tiene hacer una función, hacerla pública a todo el ámbito de nuetro código y sobre todo complicar la legibilidad del mismo que es la principal función del operador ternario, si no la única?

Todo esto hasta VB 8, en VB 9 tendremos la posibilidad de utilizar el operador ternario:

Dim mayor as Int32 = If(a > b ? a, b)

Tal vez se salga un poco de la clásica sintaxis de VB pero bienvenido sea.

En VB 9 (Agregado 11/2008): ¡Cuidado! Al ser el nuevo If de VB 9 un operador, ya no se calcula el valor de la expresión que no se retorna:

If(true, EstoSeEjecuta(), EstoNoSeEjecuta())

Pero de todas maneras el operador ¡Sigue retornando Object! y por lo tanto desaconsejo el uso del mismo para evitar boxing, casteos y demas temas.

Tambien hay que destacar que se agregó el null coalescing operator (o ??) de C#, con la siguiente sintaxis:

If(usuario, "Invitado")

Operador ternario y desempeño

En pruebas con Stopwatch, el desempeño es el mismo en ambos modos, no hay diferencia. A nivel IL el If genera más líneas, pero no redundan en el tiempo de ejecución.

Operador ternario y buenas prácticas de codificación

Acabo de leer por ahí a alguien jactandose de:

WriteLine("Login "+((condicion_booleana)?"":"in")+"válido.");

No estaré yo para competir en TopCoders, pero esto es lo que se llama algo muy muy poco recomendable, no pasa por el operador ternario el problema, si no por el hecho de querer ahorrar código haciendo malabares que después otro tendrá que entender. Esto es pereza no eficiencia.

Por último. En más de un documento donde se habla de buenas prácticas de codificación, recomiendan no usar el operador ternario, ¿por que?, bueno entiendo que lo que persiguen quienes hacen esta recomendación es código legible, pero lo que está mal es el abuso del operador, no su uso normal. Por ejemplo no es legible la sentecia:

cena = estoyPaNioquis ? HacerNioquis(harina, agua, huevos, pure):

PedirPizza(4866-2804,'Napo');

Cuando una línea excede la pantalla, ¿partimos la sentencia con el operador ternario en varias líneas? No. utilizamos If. Nuevamente la ventaja de este operador es unicamente la legibilidad del código, si no, no tiene gracia.

False: Me voy a comer pizza.