¡Hola a todos!

Nuevamente por aquí con la tercera y última parte de mis recomendaciones al desarrollar con VB.NET.

Eventos y Delegados

He tenido la oportunidad de programar con Visual Basic durante muchos años (desde sus inicios como BASIC) y cuando migré a .NET obviamente el cambio fue bastante brusco, pero aún asi lo aprendí y una cosa faltaba en mis conocimientos, el uso de los Delegados, algo que en C# prácticamente es obligatorio cuando declaras eventos, lo cual en VB.NET no ocurre. Veamos un ejemplo claro de lo que les menciono:

Snap1

En Visual Basic, los delegados son opcionales, quiere decir, que el compilador se encarga de crearlos, haciendo obviamente la tarea más sencilla, pero la consecuencia es que si tenemos que trabajar con C# se nos hará un dolor de cabeza.

Snap2

En esta porción de código, vemos como el compilador creó automáticamente el Delegado para el Evento, lo cual está fuera de nuestro control. Para llegar a esto prueben crear un proyecto en C# y referenciar sus DLL hechas en VB.

Yo recomiendo siempre, usar los delegados que vienen de por sí con el CLR, que son fácilmente compatibles con todos los lenguajes que soporta .NET. Así tenemos al Delegado Action que no devuelve ningún valor pero que puede soportar muchos valores como parámetros.

Snap3 Snap4

Expresiones Lambda

Otra característica que nos brinda el CLR es la posibilidad de declarar funciones o métodos de una manera muy rápida usando las expresiones Lambda.

Expresiones Lambda de una sola línea.

Snap5

Expresiones Lambda de más de una línea.

Snap6

Aunque aún me sigue sin gustar la sintaxis de VB.NET para las expresiones Lambda, nos pueden ahorrar mucho tiempo en no tener que declarar métodos o funciones que sólo usaremos una vez.

Funciones, Métodos y Propiedades

Otro punto controversial de este lenguaje es el hecho de que cuando usamos un método o función, los paréntesis son opcionales (algo que hasta ahora no me gusta), y es muy fácil confundirlos con propiedades.

Por ejemplo, este es el más usado:

Snap7

Como pueden observar, las funciones ToString, Trim, ToUpper se pueden usar sin necesidad de colocarle los paréntesis de apertura y cierre, lo cual me lleva a reflexionar si esto es bueno. ¡Pues claro que no! A mi parecer aunque sean opcionales los parámetros de determinada función hay que acostumbrarse a siempre usarlos.

Snap8

Si por alguna razón usamos un convertidor de código como Convert.NET de FishCodeLib, no sabrá interpretar si se trata de un método/función o propiedad, y al final sólo tendremos errores de compilación.

Snap9

Conclusiones

Hasta aquí he llegado a mis conclusiones con respecto a este lenguaje de programación que por muchos años nos ha acompañado, pero que siempre es bueno hacer las comparaciones con lo que nos tiene el CLR, para que de esta manera no nos quedemos estancados con un sólo lenguaje, el mercado actual siempre valora a aquellos profesionales que sepan programar en ambos lenguajes y saber las diferencias, porque según Microsoft, todo lo que haces con Visual Basic lo puedes hacer con C#, y claro que es cierto, pero siempre y cuando respetes las directrices del CLR.

Si quieren seguir la polémica les dejo este enlace sobre Andy Brown que declara sus 10 razones de porqué VB es mejor que C#. Personalmente yo no estoy de acuerdo con sus razones, pero la elección del lenguaje es libre y de acuerdo a sus necesidades.

Compartan y comenten.

¡Hasta pronto!

Anuncios