LAS AUDITORIAS
Las auditorias nos permiten rastrear todo el código fuente en busca de errores de diseño, implementación y ejecución. Si bien no todo lo que muestran son errores, si que da importantes consejos sobre como implemenar el código correctamente y evitar posibles errores.
Para realizar una auditoria hay que seguir estos pasos:
1. Seleccionamos la pestaña Model View en la sección del administrador de proyectos (Project Manager):
2. Pulsamos el nombre del proyecto con el botón derecho del ratón y seleccionamos QA Audits:
Se abrirá esta ventana:
Por defecto aparecen casi todas las comprobaciones activadas:
Arrays and References (colecciones y referencias): comprueba que los arrays y las referencias a objetos no apunten a valores nulos, que no excedamos el límite de un array, campos no inicializados, etc.
Branches and Loops (bifurcaciones y bucles): examina las sentencias de control para evitar bucles infinitos, si hay bloques de código que nunca serán ejecutados, etc.
Coding Style (estilo de código): esta sección comprueba inconsistencias en el código tales como comprobar si hay variables globales que son modificadas por varios bloques de código distinto con posibilidad colisión o si por ejemplo hay varias sentencias de código de una sola línea que podrían refactorizarse.
Declaration Style (estilo de declaración): comprueba si hay métodos o variables públicas que podrían estar como privados, variables que podían ser estáticas o la sobrecarga de métodos no abstractos.
Design Flaws (Imperfecciones en el diseño): comprueba si hay subclases que tienen miembros con el mismo nombre o variables que se han declarado como temporales en toda la clase pero que son utilizadas (peligrosamente) por varios métodos.
Duplicated Code (Código duplicado): revisa el código fuente en busca de bloques de código duplicados, ya sean bloques de código que se encuentran en distintas sentencias de control como en la creación de constructores de clase.
Expressions (Expresiones): revisa el código en busca de posibles divisiones por cero, el paso de argumentos a funciones con posibles valores nulos, desbordamientos positivos o negativos en variables enteras, etc.
Naming Style (Estilo de nombres): comprueba si los nombres de las variables, objetos o clases que hemos declarado tienen correctamente puestas las mayúsculas y minúsculas o si por ejemplo el nombre de una interfaz tiene el prefijo I.
Performance (comportamiento): comprueba si as ha sido utilizado como un operador o si se ha duplicado la conversión (typecast) de una variable dos o más veces.
Possible Errors (errores posibles): inspecciona el código en busca de dos bifurcaciones o más que provoquen el mismo resultado (código repetido). También mira el retorno de valores que no han sido chequeados, posibles conversiones de tipos de variable erroneos, etc.
Superflous Content (contenido superfluo): comprueba si hay miembros de clase que nunca serán utilizados, conversiones entre variables no son necesarias o si se han pasado parámetros a funciones o procedimientos que nunca serán utilizados.
Sólo tenemos que pulsar el botón Start para que comience la auditoria:
Al terminar nos mostrará en la parte inferior del editor de código el resultado de la auditoria:
En la columna Abbreviation nos indica el posible tipo de error que hemos cometido. Estos son algunos de sus significados:
NC -> Naming Concencions (conveniones de nombres).
USP -> Use Singleton Pattern (usar el patrón singleton).
FNI -> Field Not Initialized (campo no inicializado).
MCS -> Member Can be made Static (el miembro puede ser estático).
El modo de proceder a su corrección es algo extraño. Lo normal sería que si hago doble clic sobre una supuesta línea de error debería saltar a esa línea, pero no hace nada. Tenemos que pinchar la línea de error con el botón derecho del ratón y seleccionar Show Description:
Entonces abrirá una nueva pestaña encima del editor de código mostrando la descripción del error:
Ahora si hacemos doble clic sobre la línea del error entonces se cambiará de nuevo a la pestaña del editor y seleccionará el código fuente donde se encuentra el problema:
El único inconveniente que le veo a esto es que no sitúa el editor en la línea donde está el supuesto error, sino que tenemos que ser nosotros los que movamos la barra de desplazamiento lateral del editor de código hasta encontrar el código fuente seleccionado (según el número de línea). Lo tenían que haber hecho un poco más cómodo, al igual que cuando compilamos.
A veces no todos tienen porque ser errores. En la columna Severity tenemos generalmente dos tipos de información: Warning (advertencia) e Info (Información). Por ejemplo, si yo he creado una variable con notación húngara llamada sNombre me mostrará una advertencia diciendo que hemos incumplido la forma de llamar a las variables según la convención del lenguaje Pascal, donde se supone que el nombre que se le da a una variable, clase, etc. tiene que empezar por mayúsculas.
También puede quejarse si no he colocado las palabras begin y end en bloques de código de una sóla línea. Por ejemplo:
if Importe < 100 then
ShowMessage( 'Existencias mínimas' );
Según la auditoria debería hacerlo de este modo:
if Importe < 100 then
begin
ShowMessage( 'Existencias mínimas' );
end;
Así que no hay que hacerle demasiado caso a estas advertencias ya que cada programador tiene su propio estilo de escritura de código. En la parte izquierda de la ventana de auditorias tenemos los botones para guardar el resultado de la auditoria (en XML o HTML), imprimirla, refrescarla o volver a realizarla:
Hay que tener mucho cuidado con proyectos que son muy grandes ya que realizar una auditoria de los mismos puede llegar a ser desesperante. De hecho, RAD Studio se queda bloqueado de tal modo que deja Windows medio tonto.
Si tienes un proyecto con miles de líneas de código lo mejor es que selecciones en el Model View sólo el formulario que quieres auditar.
LAS MÉTRICAS
Las métricas son otro modo de evaluar nuestro código fuente estableciendo una serie de reglas que nos permitan por ejemplo fijar un máximo número de líneas por bloque de código o el número máximo de bucles anidados. Esto puede ser muy útil para fijar unos máximos y mínimos a la hora de implementar el código fuente cuando un proyecto lo realizan dos o más programadores y conviene que todos sigan un mismo estilo.
Los pasos para analizar la métrica de nuestro código son muy parecidos a los de las auditorías:
1. Seleccionamos la pestaña Model View en la sección del administrador de proyectos (Project Maganer).
2. Pulsamos el nombre del proyecto con el botón derecho del ratón y seleccionamos QA Metrics:
Se abrirá esta ventana:
Aparecen activadas todas estas opciones:
Basic (básico): cuenta el número de líneas de código de cada unidad, interfaz, clase, etc.
Cohesion (Cohesión): comprueba la cohesión de cada clase contando el número de miembros y métodos de cada clase.
Complexity (complejidad): comprueba el número máximo de bifurcaciones en el código, el número de variables locales y el peso de cada clase (a mas líneas de implementación, más pesada).
Coupling (acoplamiento): calcula entre otras cosas los valores medios y ratios máximos en el uso de interfaces, en la duplicación de métodos abstractos y el número de accesos a variables de clase directamente o mediante métodos.
Encapsulation (encapsulación): comprueba el factor de ocultación de los miembros y métodos de cada clase.
Halstead: calcula la proporción entre el número de operadores y el número de operandos.
Inheritance (herencia): comprueba el factor de herencia entre clases, la profundidad entre la jerarquía de clases heredadas así como el número de clases hijas.
Inheritance-based coupling (acoplamiento basado en la herencia): calcula el ratio y la media de herencia entre clases.
Maximum (máximo): comprueba el número máximo de niveles de identación entre los bloques de código anidados.
Polymorphism (polimorfismo): cuenta el número de métodos añadidos o sobrecargados y el ratio de polimorfismo.
Ratio: cuenta el número de líneas de comentario que hay en el código y en la documentación.
Al pulsar el botón Start comienza el análisis:
Al terminar nos abrirá una sección en la parte inferior del editor de código fuente con los resultados de las métricas:
Las métricas pueden visualizarse respecto a todo el proyecto o respecto a una unidad, clase, método, etc.
Pongamos por ejemplo este procedimiento:
procedure CrearPedido;
var
Pedido: TPedido;
begin
// Creamos el pedido
Pedido := TPedido.Create;
Pedido.ID := 1;
Pedido.sCliente := 'TRANSPORTES GARCIA, S.L.';
// Añadimos dos artículos al pedido
with Pedido do
begin
Articulos[1] := TArticulo.Create;
Articulos[1].ID := 1;
Articulos[1].sNombre := 'RUEDAS MICHELIN';
Articulos[1].Precio := 410.25;
Articulos[2] := TArticulo.Create;
Articulos[2].ID := 2;
Articulos[2].sNombre := 'FILTRO ACEITE';
Articulos[2].Precio := 176.12;
rTotal := Articulos[1].Precio + Articulos[2].Precio;
// Eliminamos los artículos
Articulos[2].Free;
Articulos[1].Free;
end;
// Eliminamos el pedido
Pedido.Free;
end;
Si examino la métrica del mismo me dirá lo siguiente:
AID (Access of Import Data – Nº de accesos a datos importados ): 0
ALD (Access of Local Data – Nº de accesos a variables de clase ) : 2
CC (Complexity Ciclomatic – Nº de ciclos ): 1
NIC ( Number of Import Classes – Nº de clases importadas): 2
NOLV (Numer of Local Variables – Nº de variables locales): 1
Si queremos averiguar lo que significa cada abreviatura, pulsamos sobre la línea de la métrica con el botón derecho del ratón (en la columna que queremos averiguar) y seleccionamos Show Description:
Nos mostrará una nueva pestaña con el significado de la misma:
También podemos ver una representación gráfica de la métrica pulsando el botón derecho del ratón sobre la rejilla y seleccionando Kiviart Chart:
Abrirá una nueva pestaña en el editor de código fuente mostrando esta gráfica:
Esta herramienta puede ser muy útil para detectar cuellos de botella en el código fuente y evitar desperdicios de memoria declarando más variables que las que necesitamos. Sobre todo viene bien en la programación de videojuegos, donde la velocidad del procesador y el consumo de memoria es crítico para el sistema.
Las métricas que vienen predeterminadas en el IDE pueden modificarse antes de pulsar el botón Start, me modo que nosotros mismos podemos establecer los máximos y mínimos según nuestro criterio.
Al igual que ocurre con las auditorias, las métricas puedes ser realmente desesperantes cuando nuestro proyecto tiene cierta envergadura. No se con tipo de hilo de ejecución han realizado ambos análisis, pero dejan a RAD Studio fuera de juego.
En el próximo artículo veremos las novedades en el lenguaje Object Pascal.
Pruebas realizadas en RAD Studio 2007.
2 comentarios:
Gracias! estoy comenzando a usar Delphi 2007 y tu artículo me sirve de mucho, sobre todo aportándome elementos para ordenar y normalizar el código. Tengo intenciones de impulsar la migración a 2007 en la empresa, las ventajas son muy importantes.
A ver si nos ponemos las pilas todos los usuarios de Delphi y hacemos que vuelva a ser uno de los lenguajes más utilizados.
Saludos.
Publicar un comentario