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

23 10 2007

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.

Anuncios

Acciones

Information

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s




A %d blogueros les gusta esto: