Está en la página 1de 7

Tcnicas para una programacin de calidad.

Tcnicas para una Programacin de Calidad. Moiss Daniel Daz Toledano


Introduccin. Qu es un error? Podramos decir a priori que un error es un fallo que se incluye en un programa estropeando el producto y afectando al cliente. Podemos verlo tambin desde otra ptica. Cuando desarrollamos software intentamos proveer de cierta funcionalidad al usuario, si esta funcionalidad no se cumple, podemos decir que el software tiene errores. Estos errores de los que estamos hablando, son errores cuantificables (detectables) por el usuario, lo que nos lleva al concepto de calidad externa del software. Sin embargo, an no hemos justificado el propsito de este artculo, por qu hacer una programacin de calidad? Porque la calidad externa del software guarda una relacin directa con la calidad interna del mismo, es decir con su estructura y codificacin. Todos queremos construir software correcto, robusto, extensible y reusable. Debemos ser conscientes que el mejor camino para lograrlo, est precisamente en hacer una programacin de calidad. Existen adems otras razones de mucha importancia para aplicar tcnicas de buena codificacin. Como desarrolladores no podemos olvidar que el cdigo fuente se mantiene y reutiliza, con lo que para facilitar estas tareas debemos cuidar nuestra programacin. El objetivo del presente artculo es presentar de una forma simple, informal y no demasiada ordenada, algunas tcnicas particulares, as como otras generales, para el ejercicio de una buena codificacin. Quizs no se est de acuerdo con algunos de estos consejos, pero al menos espero hacer reflexionar al lector sobre ellos, lo cual sin duda, traer beneficios cuantificables a nuestros desarrollos.

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.

Moiss D. Daz pg. 1

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.

Moiss D. Daz pg. 2

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

Tcnicas para una programacin de calidad.


?? ?

??

??

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

Moiss D. Daz pg. 5

Web: www.moisesdaniel.com

Tcnicas para una programacin de calidad.


End If Exit Sub errCatch: MsgBox Err.Description, ....... End Sub 2.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 End If Exit Sub errCatch: MsgBox Err.Description, ....... End Sub
?? ?

??

??

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 .

Moiss D. Daz pg. 6

Web: www.moisesdaniel.com

Tcnicas para una programacin de calidad.

Moiss Daniel Daz, Ingeniero en Informtica. Email: mailto:moises@moisesdaniel.com Web: www.moisesdaniel.com

Moiss D. Daz pg. 7

Web: www.moisesdaniel.com

También podría gustarte