Documentos de Académico
Documentos de Profesional
Documentos de Cultura
1.- Nomenclatura Los identificadores tanto de variables como de clases, funciones y procedimientos constituyen una buena parte del cdigo. Su eleccin es muy importante ya que normalizan el cdigo, y ayudan a entender el significado real de las acciones que realizan. Es muy importante usar una nomenclatura bien definida en nuestra cdigo, ya que aumenta enormemente la legibilidad y la semntica del mismo y hace ms sencillo el trabajo en equipo y la supervisin por parte de otras personas . Tener en cuenta que los excesos son negativos y que por tanto especificar reglas para absolutamente todo trae ms problemas de los que soluciona. La nomenclatura ms ampliamente extendida es la Notacin Hngara con , numerossimos defensores y detractores, cada uno bien armado de argumentos. Nos guste o no la notacin hngara, siempre podemos sacar provechosas enseanzas de esta propuesta que presupone que es mucho ms importante dar informacin en los nombres de los identificadores que poder leer el cdigo en voz alta. Una de las ideas centrales en esta notacin es la del uso de prefijos que incluyan informacin sobre el tipo de los identificadores. Esta propuesta en concreto tiene ciertas desventajas en los IDE (Entornos Integrados de Desarrollo) actuales debido sobre todo a la existencia de herramientas que nos informan conforme vamos tecleando de los diferentes mtodos, atributos, variables, etc disponibles en ese contexto particular.
Web: www.moisesdaniel.com
Tcnicas para una programacin de calidad. Sin embargo, s que podemos usar postfijos para especificar cierta informacin, en concreto informacin relacionada con el mbito de validez de las variables, tema que hasta ahora ha sido poco tratado. Una posible recomendacin sera la de usar como postfijos en los identificadores para indicar el mbito de validez de ciertas variables los siguientes caracteres: 'C' para las variables de clase y 'G' para los objetos o variables de mbito global.
modMain Public oCnnG As ADODB.Connection Esto es solo un ejemplo!! Solo usar objetos globales cuando es estrictamente necesario Public Sub main() ' algo de cdigo Set oCnnG = New ADODB.Connection oCnnG.Open "DSN=XX;SERVER=XX", "XX", "XX" 'ms cdigo End Sub
Un pequeo ejemplo de clase desarrollada segn las normas que se esbozan a lo largo de este artculo sera:
CFile Option Explicit 'Comentarios de Clase. Dim bConsistC As Boolean Dim sFilePathC As String Public Sub Init(psFilePath As String) Debug.Assert (Dir(psFilePath, vbArchive) <> "") sFilePathC = psFilePath bConsistC = True End Sub Public Function sGetFileText() As String On Error GoTo errCatch Debug.Assert (bConsistC = True) Dim iFile As Integer Dim sTempText As String iFile = FreeFile Open sFilePathC For Input As #iFile sTempText = input$(LOF(iFile), #iFile) Close #iFile sGetFileText = sTempText Exit Function errCatch: 'Error code End Function
2.- Uso profuso de Aserciones/Validaciones. Uno de los pilares de una programacin slida es conseguir detectar rpidamente los errores durante el desarrollo para evitar que estos pasen al producto que entregamos al cliente.
Web: www.moisesdaniel.com
Tcnicas para una programacin de calidad. El mecanismo principal para lograr este objetivo es el uso generalizado y profuso de validaciones en el cdigo para detectar cualquier uso no vlido de nuestros mtodos, clases, funciones y procedimientos. A esto lo denomino Blindaje de Clases y Bloques . Se recomienda como mnimo usarlas como precondiciones en nuestras funciones y procedimientos para validar: parmetros, estado del objeto, estados contextuales, etc. Un ejemplo general y abstracto podra ser el siguiente:
Class Option Explicit Comentarios sobre la clase 'Declaraciones a nivel de clase (recuerda el ltimo carcter con 'C') Public Sub SomeProcedure ( parameters list ) On error errCatch 'Validacin del estado de la clase (variables de clase y objetos relacionados con esta clase!!). Debug.Assert (bIamConsist() = true) Debug.Assert (oClass2C.State = adStateOpen) 'Validacin de parmetros, por ejemplo: Debug.Assert ( bIsValidParam1(param1) = true) 'Si es necesario Validacin de estados globales, por ejemplo: Debug.Assert (DatabaseConnectionG.State = adStateOpen) 'algo de cdigo Exit Sub errCatch: 'Tratamiento de errores. End Sub
Una posible clasificacin de las validaciones es la siguiente: ? ? ? Validaciones Internas. Se escriben para capturar estados errneas durante el desarrollo. ? ? ? Validaciones Paramtricas. ? ? ? Validaciones Contextuales a nivel de Clase. ? ? ? Validaciones Contextuales a nivel de Aplicacin. ? ? ? Validaciones Externas. Se escriben para evitar que se produzcan estados errneos en la aplicacin debidos a entradas no vlidas por parte de los componentes externos a la aplicacin (usuarios, ficheros, etc). Las nicas validaciones que permanecern en el producto final son las validaciones externas (sobre todo aquellas concernientes a la interaccin con el usuario), las internas tienen como propsito principal el ayudarnos durante el desarrollo del cdigo. De todas formas, me encuentro con cierta frecuencia con la pregunta de por qu no dejar las validaciones internas? Decir que suponen un alto coste en cuanto a rendimiento, y que no suponen ninguna ventaja para el usuario. Nos ayudan enormemente a desarrollar un cdigo de calidad ya que detectan estados y usos inconsistentes, indicndonos que existe un problema y no teniendo que descubrirlo el usuario. El tema de las validaciones es tan importante que si es necesario deberamos mantener informacin adicional en nuestras clases, mdulos, etc, para poder hacer una comprobacin ms estricta de errores. 3.- Reutilizacin de arquitecturas. Moiss D. Daz pg. 3 Web: www.moisesdaniel.com
Tcnicas para una programacin de calidad. La estructura de la mayora de las aplicaciones es muy similar. Podemos observar que existen ciertos objetos que usamos en casi todos nuestros programas. Por ello es importante desarrollar una arquitectura clara y sencilla en nuestra aplicacin, ayudndonos de desarrollos anteriores, y patrones de diseo. Haciendo un pequeo apunte sobre una cuestin especfica, podemos ver que una categora importante dentro de los objetos comnmente usados, se refiere a aquellos que van registrando informacin que se origina en cualquier parte de nuestra aplicacin mientras esta se ejecuta: los objetos Log, los Reports, e incluso algunos objetos de tratamiento global de errores. Estos han de declararse globales para que puedan ser usados desde cualquier parte de nuestra aplicacin. Se recomienda adems que tengan una interfaz pequea y sencilla para evitar dependencias con el resto del cdigo.
modMain Public oLogG As CLogObject Public oReportG as CReportObject '....Ser cuidadoso, no abusar de los objetos globales!!!!! Public Sub main() ' Algo de cdigo 'Inicializar oLogG y oReportG 'ms cdigo End Sub
Es muy importante no abusar de los objetos globales en nuestras aplicaciones ya que disminuyen la reusabilidad de nuestras clases (las hacemos mucho ms interdependientes), de hecho el nmero de objetos globales debe ser siempre muy reducido. En cualquier diseo uno de los mandamientos a seguir es desarrollar mdulos, clases, componentes, etc altamente desacoplados con el resto, por lo que vuelvo a repetir, hacer que estas clases globales tengan un interfaz pequeo, y slo sean llamadas desde puntos especficos del resto del cdigo.
4.- Algunos consejos especficos. Existen multitud de cuestiones a tener en cuenta a la hora de hacer una programacin de calidad, aqu esbozo algunos temas concretos que he encontrado importantes: ?? ? Uso de manejadores de errores. En cualquier lugar de un programa se pueden producir errores, pero es evidente que hay lugares ms propicios para que estos ocurran. En un principio deberamos de hacer un amplio uso de los manejadores de errores, pero si no es as, no olvidemos implementarlos en el cdigo que haga uso de recursos ajenos a la propia aplicacin en s: interaccin con bases de datos, protocolos de comunicaciones, ficheros, etc. De esta forma evitaremos los famosos Runtime Errors que hacen que desaparezca nuestra aplicacin. ?? ? Controlar las dependencias de cada clase. Un inconveniente bastante grande que nos encontramos a la hora de reutilizar una clase en otro proyecto, es que con demasiada frecuencia desconocimos los recursos necesarios para hacerla funcionar, es decir qu componentes utiliza, qu otras clases instancia, etc. Un mecanismo sencillo para controlar esta informacin consiste en incluir en el comentario cabecera de cada clase una lnea en la que especifiquemos claramente todas sus dependencias (componentes que usa, clases que instancia, objetos o variables globales que utiliza, etc). Moiss D. Daz pg. 4 Web: www.moisesdaniel.com
??
??
Validar la consistencia de clase. Es importante que nos aseguremos que una clase slo se use si est en un estado consistente. En VB no es obligatorio llamar a un constructor con lo que debemos asegurarnos no solo de tener uno (aunque est casi vaco) sino obligar a usarlo. Podemos tambin encontrarnos con clases cuyo proceso de instanciacin est gradado o se da en varios pasos. Tener una variable de clase que nos indique si la clase se haya en un estado consistente (es decir si ha sido iniciada con todos los datos y referencias que necesita) es algo que puede ahorrarnos muchos problemas. Por lo general yo denomino a esta variable bConsistC . ? Mantener la unicidad funcional. Hacer que las funciones que construyamos sirvan para una nica cosa. Esto hace ms fcil reutilizarlas, depurarlas, construir aserciones para ellas, entenderlas y comunicarlas. ? No incurrir en el desnivel semntico. El cdigo bsicamente se estructura en bloques de dos tipos: funciones y procedimientos. Debemos de procurar que el nivel de las abstraccin que manipulemos estn en un nivel de abstraccin similar. Esto favorece la creacin de cdigo claro, muy autoexpresivo y libre de errores, adems de que es ms fcil de entender y depurar. Lo contrario, es incurrir en lo que llamo desnivel semntico.
5.- Algunos otras reglas generales. Para finalizar este repaso informal sobre la prctica de la programacin apuntamos algunos consejos generales sobre el desarrollo de cdigo de calidad, que no debemos perder de vista.
?? ?
??
Seguimientos de cdigo. No escatimemos esfuerzos en contemplar como funciona nuestro cdigo. Hoy en da la mayora de los entornos de desarrollos permiten hacer tareas de seguimiento de una forma sencilla y rica. Es increble la cantidad de errores que uno es capaz de encontrar viendo funcionar el cdigo paso a paso, ya que en esta situacin se invierte la relacin entre el programador y el ordenador, siendo el cerebro capaz de pensar ms rpido que l, y ver ms all de lo que con anterioridad hemos escrito. ? Conseguir que el cdigo tenga una visualizacin correcta. Hacerlo ms legible. Esto se consigue formateando bien el cdigo: sangrado, colores, estructuracin, tamao adecuado de lneas, extensin correcta en funciones, procedimientos, clases, etc.
Cul es ms fcil de leer? 1.Public Sub Procedure(parameters list) On Error GoTo errCatch Debug.Assert (ValidateSomething()) If bSomeCondition = False Then DoSomething Else For each object in colObjects If bSomeOtherCondition = false then DoOtherThings End If Next
Web: www.moisesdaniel.com
??
??
Construir interfaces grficos consistentes. Es importante situar al usuario ante lo conocido, y por ello no debemos temer el copiar el estilo de aplicaciones comnmente usadas que sitan rpidamente a nuestros usuarios sobre la pista de cmo deben de interaccionar con la aplicacin. Es importante usar estructuras visuales que reflejen aquello que se est manejando (las estructuras que estn por abajo). Esto hace que el usuario pueda olvidarse que existe una aplicacin entre l y sus datos. ? Centrarse en lo importante. No todas las opciones de un programa tienen igual importancia, con lo que no debemos de olvidar asegurarnos que aquello que de verdad tiene que hacer una aplicacin lo haga bien. ? De forma general, no sacrificar claridad por velocidad. La velocidad depende bsicamente de la arquitectura y tecnologa usada en una aplicacin y no de detalles concretos que hayamos desarrollado en nuestro programa.
Bibliografa: ?? ? Maguire, Steve. Cdigo Sin Errores. McGraw-Hill, Microsoft Press (1994). ?? ? Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994. ? ? ? Meyer, Bertrand. Construccin de Software Orientado a Objetos. Prentice may, 1999. ?? ? Hamilton, J.P. Fifty Ways to Improve Your Visual Basic Programs, http://vb.oreilly.com/news/vbshell2_0901.html . ?? ? Daz Toledano, Moiss Daniel. Principios de Diseo Web, http://www.moisesdaniel.com/es/wri/PrincDisWeb.html .
Web: www.moisesdaniel.com
Web: www.moisesdaniel.com