Hola a todos, nuevamente aquí me tienen con la segunda parte de las recomendaciones para desarrollar con Visual Basic .NET, hay muchas más recomendaciones por cierto, pues como les mencionaba en el post anterior, Visual Basic no es malo, lo malo es como lo usan.

Aqui vamos.

Espacios de Nombres Implícitos

Hasta ahora no me explico porque Microsoft conserva esto, pero siempre hay que tener cuidado con los Espacios de Nombres, debido a que Visual Basic no es Case Sensitive, nos puede dar problemas sino respetamos un orden establecido.

Por ejemplo si tenemos la siguiente estructura:

Snap1

Podemos darnos cuenta que todos los archivos contenidos dentro del ensamblado “heredan” el nombre del Ensamblado como Espacio de Nombres, algo que podemos cambiar si nos vamos a la carpeta My Project del Proyecto y escogemos la pestaña Aplicación.

Snap2

Tengan en cuenta que no es lo mismo el nombre del ensamblado y el Espacio de Nombres a usar.

Es mejor asegurarse yendo a la herramienta Vista de Clases, el cual nos dará todo el árbol de nuestras clases, espacios de nombres y ensamblados que forman parte de nuestro proyecto y ajustar lo necesario, una buena organización se traduce en una mejor mantenibilidad.

Snap11

En C# pasa todo lo contrario, los espacios de nombres se autogeneran dependiendo de la estructura de carpetas del proyecto.

Snap3Snap4

Conversiones implícitas

Este punto también es controversial, por una parte Visual Basic nos alivia tener que lidiar con conversiones pero por otra parte no tenemos control sobre éstas, debido a que tienen un alto coste de rendimiento con el tiempo, pues si nuestros proyectos son muy grandes y abusamos de las conversiones implícitas podremos ver como el rendimiento de nuestra aplicación se va ralentizando.

Es por esto que los desarrolladores de C# tienen el falso argumento de que Visual Basic es más lento, en realidad, tiene que ver mucho con la forma de programación.

Este  es un ejemplo claro de conversión implícita:

Snap5

Lo ideal sería:

Snap6

Tengan en cuenta siempre, de que ambos lenguajes compilan a código intermedio (MSIL) lo cual al final es lo mismo, dichos lenguajes deberían tener el mismo rendimiento.

Cosas heredadas de VB6

Cuando en diferentes oportunidades tuve la “suerte” de dar mantenimiento a aplicaciones desarrolladas bajo VB.NET me he topado con que la gente sigue usando cosas que para mí, ya están desfasadas y que de alguna forma no ayuda a que cuando tengas que ver otro proyecto en C# puedas “migrar” fácilmente.

Vamos al algunos ejemplos para verlo más claro:

MsgBox

Snap7

Con mucha pena veo que usan esta función para mostrar un cuadro de diálogo en Windows Forms, a mi parecer ya no deberían usarla, sino más bien usar MessageBox.Show() que es la forma estándar del CLR.

Snap8

Conversores de VB6

¿Has usado alguna vez CInt, CDate ó CLong? Recomiendo siempre usar los métodos de conversión de la clase Convert, que se encuentra en el espacio de nombres System.

Snap13

Constantes de VB6

Las constantes de VB6 aun permanecen entre nosotros, por ejemplo, he visto mucho código que usan para el separador de línea vbCrLf ó vbLf.

Snap9

Es mejor usar constantes estándares del CLR.

Snap10

Uso del underscore (guión bajo) como separador

Hasta antes de Visual Basic 10 (sí, Visual Studio 2010), la única forma de separar una línea de código muy larga en varias líneas era usando el guión bajo ( _ ) y un salto de línea. A partir de Visual Studio 2010 puedes partir una línea simplemente realizando el salto de línea.

Snap14

¿No lo sabías? Ahora sí.

Esperen la tercera y última parte que seguro les encantará. Compartan y comenten.

Anuncios