En el post anterior, hemos creado nuestro propio Quality Profile PL/SQL, activando todas las 132 reglas presentes en SonarQube. Luego, hemos ejecutado de nuevo nuestro análisis de código PL/SQL.
Pues vamos a poder trabajar con todas las normas de calidad del Quality Profile predeterminado de SonarQube y seleccionar las que nos interesan para crear un cuadro de mando para nuestro entorno de demos.
Las reglas de tipo Blocker
Primero, encontramos 16 defectos con la regla ‘Use IS NULL and IS NOT NULL instead of direct NULL comparisons’. ¿De que se trata?
Un drill-down desde esta lista de defectos y SonarQube nos permite acceder al código erroneo.
Podemos ver que el programador realiza una prueba con la variable ‘v_periodo’ con el fin de comprobar si se trata de una cadena vacía, que probablement se ha inicializado de esta manera, o porque este valor ‘vacio’ se asigna en alguna parte del algoritmo. Por ejemplo:
DECLARE name v_periodo varchar(10) := ''
El problema es que:
- Oracle trata una cadena vacia como un valor NULL. Entonces, con el tratamiento anterior, nuestra variable no comporta una cadena vacia, pero el valor NULL.
- Oracle hace la diferencia entre una cadena vacía y un valor NULL. Entonces, el test:
IF v_periodo = ''
devuelve false ya que v_periodo no comporta pas una cadena vacia, pero un valor NULL. El tratamiento correcto es:
IF v_periodo IS NULL
Aquí tenemos un buen ejemplo de un ‘bad practice’ de programación que llevará sin duda un error de lógica en la aplicación, ya que la condición probada (cadena vacía) nunca será posible, y por lo tanto nunca se hará el tratamiento correspondiente.
Y, por supuesto, como si eso fuera poco, nos encontramos con este error duplicado unas pocas líneas más abajo:
Creo que debe existir en alguna parte un teorema informatico o alguna variante de la ley de Murphy, que establece que el número de Copiado-Pegado de una instrucción incorrecta es proporcional a la gravedad de este error.
Los otros dos defectos de tipo ‘Blockers’ son claros y basta con echar un ojo a la documentación en SonarQube para entender porque es incorrecto y con cual consecuencia:
Un COMMIT o un ROLLBACK en un trigger lleva un error ORA-04902. Se necesita utilizar una PRAGMA (instrucción de compilación) para declarar una transacción para tal manipulación. Bueno, yo cuestionaría cualquier instrucción de tipo DML (Data Manipulation Language) dentro de un trigger.
Se ha declarado una variable dos veces, lo que significará un un error Oracle PLS-03371. Me gusta especialmente que SonarQube indica las 2 líneas en las que esta instrucción se duplica, debido a que es uno de los defectos más difíciles de investigar, sobre todo en un programa como este que tiene decenas de miles de línea. Esto es común en las aplicaciones más antiguas PL/SQL de tipo ‘Legacy’.
¿Qué podemos decir acerca de estas 3 reglas ‘Blockers’? En primer lugar, se justifica complementament su nivel de gravedad:
- En el primer caso, esta ‘malpractice’ de programación lleva a un error lógico y un bug muy muy posible.
- Y los dos casos siguientes son bugs que interrupen la aplicación.
Por lo tanto, son tres reglas para cuales no se permitirá ninguna violación: tolerancia cero, estos defectos deben ser corregidos inmediatamente.
Segunda observación: estas reglas son conocidas, si consideramos el escaso número de casos encontrados. Sin embargo, no se puede evitar:
- Una nueva persona en el equipo, posiblemente principiante, pero en cualquier caso que no conoce la ‘best practice’. Apuesto a que este es el caso de la primera regla (uso de NULL / NOT NULL exclusivamente), y con un mismo programador que ha utilizado una sintaxis incorrecta y luego hizo Copy/Paste en todas partes.
- Incluso cuando todo el mundo conoce la regla, es siempre posible la falta de atención o el olvido momentáneo.
Es fácil olvidarse de declarar una transacción o que una variable ya se ha declarado unas pocas decenas (o cientos) de líneas más arriba. Afortunadamente, el plugin PL/SQL SonarQube nos permite identificar y corregir estos errores de atención de manera rápida y fácilmente. Aprecio especialmente poder bajar hasta la línea de código, validar el defecto y decidir por su remediación inmediata.
En el próximo post, vamos a hablar de los defectos de tipo ‘Critical’. De nuevo, feliz año 2014, y nos vemos pronto.
Esta entrada está disponible también en Lire cet article en français y Read that post in english.