Estilos y Convenios en VB6

Cuestión de Buenos Modales, Mañas, y Más

Por Harvey Triana, Mayo 1998

Visual Basic clásico siempre ha sido víctima del dilema de « sé sencillo y a la vez potente ». Para ser franco, deberíamos llamar a esto La Entropía del Basic. Si nos detenemos a analizar, sencillo o avanzado son conceptos subjetivos y, hoy día, lo importante es lo ponente que sea el lenguaje. Como caso particular, por ejemplo, me perdonaran los programadores avanzados, - No considero como avanzado la utilización de la API en Visual Basic. Para explicarme mejor, es cuestión de conocer, de saber donde están las cosas y de como usarlas, - de hecho esto lo hace sencillo. ¿Llamaríamos al idioma Chino avanzado?, Para un niño Chino es natural el idioma y no tiene nada de avanzado, mientras que el Español debe parecerle un mar de confusiones. Supongo que me hice entender. Si me preguntas ¿qué es avanzado?, Diré que avanzado es idear algoritmos y llevarlo al código, ya sea que escribas en C++, Visual Basic, Delphi, etc. No es mi intensión ni quiero plantear una discusión que indudablemente tiene puntos de vista personales. Bien dicho Nietzsche, - somos hiperboreos.

Después de esta irreverente introducción, les presentaré mi estilo y conveniencias para programar con Visual Basic. Tendamos a ser formales pero no formalistas. Existe una convención que tiene como mil años y le llama norma Húngara. A grosso modo, la norma Húngara (dicen que la creo un desarrollador Húngaro de MS) es un conjunto de normas que todos seguimos más o menos y se aplica en cada lenguaje de programación moderna. No voy a exponer esta norma ni mucho menos, daré mis retoques que les pueden servir para entender mejor mis códigos, seguir mis buenas mañas, o simplemente para nada.

Del Estilo

Declaración de Variables. Primer mandamiento: Option Explicit. ¿Por qué aun no es una norma predeterminada en Visual Basic?, O quizá aún ¿obligatoria? - Si, por aquello del abuelo Basic y el ribete de fácil, a estas alturas no merece suficiente justificación. Creo que programador Visual Basic que se respete usa Option Explicit, aunque hay casos de casos. Creo que se sabe de sobra los beneficios de usar la directiva Option Explicit. Valga mencionar que Option Explicit no te asegura que avisará de inmediato cuando una variable no ha sido declarada, Visual Basic lo hará cuando se intente usar la variable no declarada, no obstante el compilador verificará por completo la orden Option Explicit (la compilación completa en el entorno de desarrollo se logra con Ctrl+F5).

Tipo Predeterminado. Declaro por defecto todas las variables de tipo entero corto, es decir, al principio de cada modulo uso DefLng A-Z. Así como C, me gustaría que Visual Basic lo usara como norma predeterminada, aunque sé que nunca será una norma Basic. La razón básica es que usamos muchas variables es de tipo entero y bastará un Dim miVar, Private miVar, Static miVar, etc. Sobra decir que un entero ya sea largo o corto tiene una eficiencia abismalmente superior frente a un Variant que apunta a un Integer, y más aun en el código compilado (modo nativo).

NOTA. DefLng A-Z es preferible a DefInt A-Z en sistemas de 32 Bits (el sistema nativo de memoria para 32 Bist agrega complejidad al tipo Integer, lo que lo hace menos eficiente). En sistemas de 16 Bits DefInt A-Z es el indicado.

Contadores e Indices de Matriz. Adopte una vieja norma de FORTRAN (mi primer lenguaje) y es que mis contadores son i, j, k, l, m, n (para lo único que se uso estas variables), i-l para índices de arreglo (array) y n-m para número de elementos de los arreglos,. Nunca he prescindido de esta regla. La norma Húngara dice que un contador se precede con i, p.e. iContadorX, - esto es demasiado para mí, aunque cumplo la regla para un tipo definido, he aquí un ejemplo:

Private Type udt_IDField
    IDName  As String * 24
    IDValue As Long
End Type
Private ID() As udt_IDField, nID, iID

Nota. El prefijo udt es User Define Type (norma Húngara). La variable nID contendrá el número de elementos del arreglo ID, mientras iID será el contador de incide (ambos enteros cortos dada la cláusula DefInt A-Z).

Caracteres de Tipo. Olvidémonos de usar caracteres para definir tipos primitivos (norma que sigo desde mis primeros pasos con QuickBasic). Son horriblemente feos y recuerdan los tiempos en que Basic era negro y estrenaban Nosferatu. Ni siquiera recuero los caracteres. Valga aclarar que las funciones intrínsecas para sartas tienen un rendimiento ligeramente mejor cuando empleas su carácter de tipo $, es decir, Mid$(...) es más rápida que Mid(...) (para variantes y sartas). Para ser franco ni siquiera uso el tal $ en este caso. Pienso de Visual Basic debiera ser estricto y suministrar StrMid(...) y VarMid(...); Tal vez esta seria la única manera para enterrar ese fantasma de los caracteres para tipos.

Nombres y Declaración de Variables. No uso prefijos para los tipos primitivos (básicos). Posiblemente esta sea mi peor manía, pero no daré marcha atrás. Me basta con la declaración de la variable. Pienso que es más elegante Dim MyWord que Dim strMyWord o Dim sWyWord. Además, si la variable empieza con una mayúscula, sé que es un tipo básico (vaya, me lleve un punto a favor). Respecto a la declaración de variables, siempre uso una identación especial para alinear el As Tipo, por ejemplo:

Private UserEntry      As Boolean
Private Reposition     As Boolean
Private Records        As Variant
Private JumpResize     As Boolean
Private AutoDefaults() As Integer

Esto da mucha elegancia al código, y por demás facilidad de lectura. Por lo menos me gustaría que los programadores siguieran esta norma.

Los Comentarios. Esta si es bien particular. Si han seguido mis líneas, habrán notado que precedo los comentarios con doble barra o Slash. La historia de esto es la siguiente. Hace como un año o más estudie J++ para ver que era el alboroto. Recuerdo que hice una aplicación sencilla y una dos miniaplicaciones (applets), no sin intentar y depurar mucho y recompilar mil veces (nada menos que acceso a datos usando un COM de Java). Bien, en esta tarea imprimía el código de vez en cuando para leerlo cómodamente, y de pronto me di cuenta de algo especial, ¡ cómo resaltan y se ven de bonitos los comentarios con esas dos patitas ! - Desde ese momento uso doble barra en los comentarios Visual Basic, para darle apoyo a esa estúpida comillita que nos dejaron. A veces uso '** en vez de '// para recordarme que debo revisar este bloque, y regresar al rápidamente con comandos de Búsqueda en el IDE. Otra cosa que me parece muy bien presentada es alinear los comentarios cuando se escriben a la derecha, p.e.:
'//Configuración DBGrid
Private ColDescrip()  As String  '//Mantiene los textos de la línea Estado
Private ColAncho()    As Integer '//Mantiene el ancho de las columnas 
Private IndiceDeLista As Integer '//Indice actual de una lista desplegable

Nombres de Objetos. Este es mi más cercano encuentro con la norma Húngara (en general he visto que la mayoría de los programadores Visual Basic la siguen). La norma dice que por ejemplo un TextBox se bebiera bautizar txtNombre, pero en mi rebeldía adopte un txt_Nombre. Para ser franco algo me dice que ese txt, pegado, mancha mi nombre del control y en cierta manera lo tergiversa. Bendito seas Visual Basic que nos dejaste incluir subrayado en los nombres de variables aunque no sea desde el principio. La regla aplica a cualquier objeto, por supuesto incluidos los controles, y son tres caracteres mnemotécnicos en minúscula para el nombre del objeto. Generalmente uso esta misma nemotecnia para declarar variables generales de objeto, por ejemplo, Dim frm As Form, Dim ctl as Control, Dim tbr As ToolBar, etc. Como una excepción, me paso por la faja la regla del prefijo con algunos objetos DAO. Por ultimo, por favor, jamas dejar nombres como Text1, salvo para ejemplos muy sencillos, porque pobre del que quiera leer su código.

Clases. En general, sigo las normas muy similares a las de Java (y en cierta manera Visual Basic) cuando creo clases. Como una particularidad, nunca precedo el nombre de una clase con la letra C. En particular mis nombres de clases tienen el estilo cls_NombreDeClase, y para el componente com_NombreDeComponente.

Existen michos otros detalles menores que no merece nombrar. Como podrán deducir, hay que hacer las cosas sencillas pero no más (sabia frase).

Resumen de Norma Húngara

Bien, si desean seguir al pie de la letra la norma Húngara he aquí lo básico:

Convenio	Ejemplo
Los nombres de clases empiezan con letra capital.	MathComplex
Los datos miembro son precedidos con m_	Private m_Text
Los objetos comienzan con letra minúscula y tienden a incluir el nombre de la clase.	Dim my MathComplex As New MathComplex
Los tipos primitivos preceden con un carácter convenido.	Dim bFlag As Boolean Dim yByte As Byte Dim sWord As String Dim lCount As Long Dim nCount As Integer Dim fValue As Single Dim dValue As Double Dim vPointer As Variant
Las constantes se escriben en formato combinado mayúsculas minúsculas. Excepto en el caso de constantes para funciones API en que el nombre de la constante va en mayúsculas.	Public Const Pi As Double = 3.14159
Los Métodos y Propiedades inician con mayúscula y no usan caracteres de tipo.	Public Property Let Text(New_Text As String)
Variable global (de módulo)	Public gsMyString As String
Formulario Dialogo Modal	Private dlgNombreForm As frmNombreForm

Una parte que encontré un poco diferente de la norma Húngara es la siguiente. Prefijos: C: Clase, F: Formulario, T: Tipo, X: Control ActiveX, D: Documento ActiveX, P: Página de Propiedades, E: Enumeración, Y: Clase de interfaz para Implements, M: Módulo estándar, G: Módulo de clase de objeto global. Datos de Programación Avanzada con Visual Basic de McKinney.

La documentación visual Basic trae algunos convenios para componentes en los temas "Directrices ara asignación de nombres de objetos"y en "Estándares y directrices". Creo que los documentos también se encuentran en Libros en Pantalla.

Pecados de Visual Basic

Visual Basic dentro de su inconmensurable elegancia, es permisible y deja que se le den patadas como estas:

Rem. La lista la cabeza Rem, posiblemente los jóvenes no sepan que Rem es un comando para comentarios (que vergüenza). No obstante, seria genial si Visual Basic en futuras versiones nos entregara la siguiente posibilidad:
    Rem
        Este es un comentario de muchas
        Líneas
    End Rem
Carencia de Iniciación de Variables. A estas alturas ya deberian porder hacerse cosas como esta:

Dim x As Single = 3.1416

Aunque siempre existe la posibilidad de iniciar variables en código aparte, es una carencia que no perdonamos los programadores de recorrido. Visual Basic es el único lenguaje que le hace falta esto, pero ya casi.

While...Wend. Tendremos que hacer un exorcismo para librarnos de este bloque estructurado. Do...Loop esta tan elegante y potente que según he leído es envidiado por otros lenguajes, incluyendo C y Pascal.

Dim a Nivel de Modulo. Dim a nivel de modulo me parece obsoleto y poco formal. Global es cuento parte y deberá olvidarse por completo (Visual Basic está tan apenado con Global que ni siquiera lo documenta en las ultimas versiones). Por simple estética, usemos Private o Public en este caso.

Goto en Contextos fuera de Captura de Errores y el viejo Gosub. Goto será perpetuo mientras existan errores inevitables. Creo que ya no existen programadores Visual Basic que usen Goto en otro contexto. Respeto a Gosub, tengo que ser sincero y confesar que aunque pocas veces lo uso, aun me hace falta; el caso particular es cuando dentro de un procedimiento la identación me lleva a extremos, entonces bifurcó con a una subrutina con Gosub, en otro caso tendría que llamar a un procedimiento con todas las variables declaradas en el que trabajo, y esto sinceramente me parece tonto. La salida con Gusub...Return en este caso me parece limpia y útil (le da lectura fácil al código). De otra parte, On Gosub realmente paso a la historia (gracias a Select Case).

El Operador Diferente. Afortunadamente en muy pocas ocasiones del código moderno Basic he visto el operador: <>. Es tan poco estético que ha sido reemplazado por la palabra clave Not, es decir, Exp1<>Exp2, por Not Exp1 = Exp2. La segunda sintaxis es más inteligente y clara. ¿Cuál es más eficiente, probablemente la diferencia sea ínfima, sin embargo si le preocupa Not esta documentado como un operador y no como una función. El operador <> no lo uso desde que tengo memoria.

El Pecado Let. Visual Basic arrastra el pecado de Basic de no usar un operador diferente para igualdad y para asignación. Me explico, para un compilador comparar y asignar son dos ordenes distintas, esto lo entendieron los demás lenguajes como C y Pascal desde su nacimiento, desafortunadamente Basic por hacer fácil e intuitivas las cosas dejo correr el operador = para ambos casos, y optó por una sentencia Let como una alternativa para asignaciones. La pregunta importante es: cual es más eficiente: (1) x = 1, y (2) Let x = 1. La respuesta le sorprenderá, pues (2) es mejor interpretado por el compilador. ¿Pero quien se va a ponerse a usar Let en algo tan lógico como una asignación?, Simplemente nadie, Visual Basic llevara su pecado siempre.

Caracteres de Tipo. Creo que ya di una buena disertación de los dichosos caracteres de tipo. Me queda la esperanza que en futuras versiones Visual Basic los elimine del lenguaje.

Option Base. Una buena norma en Visual Basic es siempre declarar los arreglos especificando las dimensiones inferior y superior, es decir Dim x(IndiceInicio To IndiceFinal) As Typo. Me confieso, ni siquiera me acuerdo para que es Option Base ni me interesa.

Líneas de Código con Números. ¿Por que es posible hacer esto?, ¿Qué pretenden los desarrolladores de Visual Basic manteniendo este legado totalmente obsoleto?. No hay más que decir.

Tienen que haber más cosas obsoletas en Visual Basic, que en este momento no recuerdo. Creo que es suficiente.

Para no comprometerme negativamente, diré que hablar de los aciertos de Visual Basic seria interminable, y solo basta leer los manuales para salir de dudas. Pienso que Visual Basic seguirá evolucionando de tal manera que será el lenguaje de programación para aplicaciones de gestión más potente que exista, ¿O no lo es ya?.

Corolario

Cada uno tiene su estilo y es válido. Simplemente, si nos ponemos de acuerdo en ciertas cosas, los programadores Visual Basic lograremos comunicarnos mejor. Mi estilo y convenios no son una panacea pero me ayudan bastante y me siento satisfecho con la formalidad y estética del código, así de esta manera pienso que les puede suceder a otros.