Hoy quiero compartir con ustedes algo que siempre se ha debatido mucho.

Durante años los desarrolladores de C# y VB han debatido sobre cual lenguaje es mejor que el otro, hay que aclarar algunas cosas que a mi parecer, Visual Basic sigue arrastrando cosas desde versiones como Visual Basic 6, que fue muy popular en su época, y que si bien ya es prácticamente un lenguaje obsoleto, aún en las versiones actuales (Yo uso Visual Studio 2013) se siguen soportando características del pasado.

Con esto no quiero decir que Visual Basic es malo, lo malo es que aun soporta cosas que al fin y al cabo constituyen malas prácticas.

Repasemos algunas:

visual basicversuscsharp

Option Strict

Lamentablemente hasta el día de hoy esta opción esta deshabilitada de forma predeterminada, esta opción si estuviese habilitada, impide que cuando declaremos una variable de un tipo por ejemplo String, no podamos asignar un valor distinto al declarado.

Por ejemplo, cuando está deshabilitado se pueden hacer cosas como esta:

optionstrictoff

Y si en caso estuviese habilitado:

Option Strict habilitado

Nos mostraría estas asignaciones como errores de compilación, lo cual tenemos que subsanar antes de generar nuestro ensamblado.

La buena noticia es que podemos habilitar esta característica desde 3 ámbitos distintos:

Por archivo de código:

Simplemente escribiendo en la primera línea de código

Option Strict por codigo

Por proyecto:

Doble click sobre la carpeta My Project del Proyecto, pestaña Compile y luego eligen la opción:

Option Strict por Proyecto

De por vida para los proyectos nuevos:

En el Menú Tools -> Options -> Projects & Solutions -> VB Defaults

VBDefaults

Evidentemente esta opción solo permitirá para los nuevos proyectos, no es retroactivo. Como pueden ver C# ni siquiera contempla esta opción ya que esto es por defecto.

Case Sensitive

Otra característica de Visual Basic es que podemos declarar una variable en Mayúsculas por ejemplo, y luego referenciarla en minúsculas, y nos dará un resultado identico, no habrá ningun problema ni ningun error de compilación.

CaseSensitive

Pero (siempre hay uno) es una mala práctica no declarar las variables correctamente, ya que si nos acostumbramos a hacer esto, a la larga, no tendremos un estándar, y eso nos puede acarrear horas y horas para dar mantenimiento a un sistema más aun cuando el proyecto es grande.

Nuevamente, C# es muy estricto en este tema (igual que Java) y requiere que las variables siempre sean sensibles a las mayúsculas o minúsculas.

Importaciones a Nivel de Proyecto

Esta es una característica que me encantó mucho al inicio cuando desarrollaba con Visual Basic, pues si requería referenciar a una clase que esté en otro Espacio de Nombres y lo necesitaba en muchas clases de mi(s) proyecto(s) simplemente me dirigía a la carpeta My Project del Proyecto, luego a References y en el cuadro inferior marcaba los Espacios de Nombres que tendrían que ser referenciados en TODAS las clases del proyecto en cuestión.

ImportsProject

Esto supone un “ahorro” de escritura de código en todas las clases, pero (otro más), cuando tienes muchísimas clases, en proyectos inmensos, resulta todo un lío saber a cual Espacio de Nombres pertenecen, salvo que vaya presionando la tecla F12 (Go to Definition) en cada clase que requiera saber a que Espacio de Nombres o emsamblado pertenece.

GoToDefinition

Nuevamente, C# te obliga a que declares los Using (Imports en VB) en cada clase que codifiques.

Módulos vs Clases

Este es un tema polémico, los módulos, son una herencia del viejo Visual Basic 6, ya que sobre este tipo de clases especiales, podemos declarar variables, constantes, enumeraciones, tipos, eventos y delegados de forma pública sin requerir crear una instancia de la misma, esto puede resultar muy cómodo si deseamos centralizar en un sólo lugar.

Modulos

Pero (sí, aquí voy otra vez), podemos acceder a dichos miembros, sin necesidad de llamar explícitamente al módulo que lo contiene y aquí viene el terrible error, que si procedemos con esto a lo largo de la construcción de nuestro proyecto, podremos confundirnos con facilidad a que módulo pertenece un miembro si es que manejamos más de uno.

InvocandoModulo

Lo ideal es siempre acostumbrarse a usar el nombre del módulo, luego un punto y luego el miembro al cual queramos acceder.

ModuloOK

C# no permite crear módulos, en su lugar están las clases, pero podemos definir clases estáticas por si necesitamos usar una en particular que sólo declare miembros que necesitemos acceder de forma pública desde todo el proyecto y no requerimos crear una instancia de dicho objeto.

Esto es sólo es la primera parte de mis recomendaciones de Visual Basic .NET, estén atentos a la segunda parte.

Espero que les sirva.

Anuncios