{"id":946,"date":"2014-01-05T14:18:21","date_gmt":"2014-01-05T13:18:21","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=946"},"modified":"2014-01-05T15:31:06","modified_gmt":"2014-01-05T14:31:06","slug":"analisis-plsql-con-sonarqube-blockers","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/analisis-plsql-con-sonarqube-blockers\/","title":{"rendered":"An\u00e1lisis PL\/SQL con SonarQube – Blockers"},"content":{"rendered":"

\"PLSQL_BlockersCritical\"<\/a>En el post anterior, hemos creado nuestro propio Quality Profile PL\/SQL,<\/a> activando todas las 132 reglas presentes en SonarQube. Luego, hemos ejecutado de nuevo nuestro an\u00e1lisis de c\u00f3digo PL\/SQL.<\/p>\n

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. <\/p>\n

Las reglas de tipo Blocker<\/h2>\n

\"Blockers\"<\/a><\/p>\n

Primero, encontramos 16 defectos con la regla \u2018Use IS NULL and IS NOT NULL instead of direct NULL comparisons\u2019. \u00bfDe que se trata?<\/p>\n

\"RuleNULL\"<\/a>Un drill-down desde esta lista de defectos y SonarQube nos permite acceder al c\u00f3digo erroneo.<\/p>\n

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\u00eda, que probablement se ha inicializado de esta manera, o porque este valor ‘vacio’ se asigna en alguna parte del algoritmo. Por ejemplo:<\/p>\n

DECLARE\r\n   name v_periodo varchar(10) := ''<\/pre>\n
El problema es que:<\/p>\n
    \n
  1. Oracle trata una cadena vacia como un valor NULL. Entonces, con el tratamiento anterior, nuestra variable no comporta <\/strong>una cadena vacia, pero el valor NULL.<\/li>\n
  2. Oracle\u00a0hace la diferencia entre una cadena vac\u00eda y un valor NULL. Entonces, el test:<\/li>\n<\/ol>\n
    IF v_periodo = ''<\/pre>\n
    devuelve false<\/strong> ya que v_periodo no comporta pas<\/strong> una cadena vacia, pero un valor NULL. El tratamiento correcto es:<\/p>\n
    IF v_periodo IS NULL<\/pre>\n
    \n
    \n
    Aqu\u00ed tenemos un<\/span> buen ejemplo de un ‘bad practice’ de<\/span> programaci\u00f3n\u00a0<\/span>que<\/span> llevar\u00e1 sin duda<\/span> un error<\/span> de l\u00f3gica<\/span> en la aplicaci\u00f3n<\/span>, ya que la<\/span> condici\u00f3n probada<\/span> (cadena vac\u00eda<\/span>)<\/span> nunca ser\u00e1<\/span> posible,<\/span> y por lo tanto<\/span> nunca<\/span> se har\u00e1<\/span> el tratamiento correspondiente<\/span>.<\/span><\/span><\/span><\/p>\n
    Y, por supuesto<\/span>, como si<\/span> eso fuera poco<\/span>, nos encontramos con<\/span> este error<\/span> duplicado<\/span> unas pocas l\u00edneas<\/span> m\u00e1s abajo<\/span>:<\/span>\"RuleNULL2\"<\/a>Creo que debe existir en alguna parte un teorema informatico o alguna variante de la ley de Murphy, que establece que el n\u00famero de Copiado-Pegado de una instrucci\u00f3n incorrecta es proporcional a la gravedad de este error.<\/p>\n
    Los otros dos defectos de tipo ‘Blockers’ son claros y basta con echar un ojo a la documentaci\u00f3n en SonarQube para entender porque es incorrecto y con cual consecuencia:<\/p>\n<\/div>\n<\/div>\n
    \"RuleTrigger1\"<\/a><\/p>\n
    Un COMMIT o un ROLLBACK en un trigger lleva un error ORA-04902. Se necesita utilizar una PRAGMA (instrucci\u00f3n de compilaci\u00f3n) para declarar una transacci\u00f3n para tal manipulaci\u00f3n. Bueno, yo cuestionar\u00eda cualquier instrucci\u00f3n de tipo DML (Data Manipulation Language) dentro de un trigger.<\/p>\n
    \"RuleBlocker3\"<\/a><\/p>\n
    Se ha declarado una variable dos veces, lo que significar\u00e1 un un error Oracle PLS-03371. Me gusta especialmente que SonarQube indica las 2 l\u00edneas en las que esta instrucci\u00f3n se duplica, debido a que es uno de los defectos m\u00e1s dif\u00edciles de investigar, sobre todo en un programa como este que tiene decenas de miles de l\u00ednea. Esto es com\u00fan en las aplicaciones m\u00e1s antiguas PL\/SQL de tipo ‘Legacy’.<\/p>\n
    \u00bfQu\u00e9 podemos decir acerca de estas 3 reglas ‘Blockers’? En primer lugar, se justifica complementament su nivel de gravedad:<\/p>\n