{"id":1502,"date":"2014-01-04T08:52:13","date_gmt":"2014-01-04T07:52:13","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=1502"},"modified":"2014-01-05T16:58:42","modified_gmt":"2014-01-05T15:58:42","slug":"analyse-plsql-sonarqube-blockers","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/analyse-plsql-sonarqube-blockers\/","title":{"rendered":"Analyse PL\/SQL avec SonarQube \u2013 Blockers"},"content":{"rendered":"

\"PLSQL_BlockersCritical\"<\/a>Dans le post pr\u00e9c\u00e9dent, nous avons cr\u00e9\u00e9 notre propre Quality Profile PL\/SQL<\/a> en activant toutes les r\u00e8gles existantes dans SonarQube, au nombre de 132. Puis nous avons ensuite relanc\u00e9 l\u2019analyse cr\u00e9\u00e9e pr\u00e9c\u00e9demment.<\/p>\n

Nous allons ainsi pouvoir travailler avec l\u2019ensemble des r\u00e8gles du Quality Profile par d\u00e9faut de SonarQube et s\u00e9lectionner celles qui nous int\u00e9ressent afin de cr\u00e9er un tableau de bord \u2018PL\/SQL\u2019 pour notre environnement de d\u00e9mo. <\/p>\n

Les r\u00e8gles de type Blocker<\/h2>\n

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

Nous pouvons constater tout d\u2019abord 16 d\u00e9fauts concernant la r\u00e8gle \u2018Use IS NULL and IS NOT NULL instead of direct NULL comparisons\u2019. De quoi s’agit-il ?<\/p>\n

\"RuleNULL\"<\/a>Un drill-down depuis cette liste de d\u00e9fauts et SonarQube nous permet d’acc\u00e9der au code incrimin\u00e9.<\/p>\n

Nous pouvons voir que le programmeur effectue un test sur la variable ‘v_periodo’ afin de v\u00e9rifier si celle-ci est une cha\u00eene (de caract\u00e8res) vide, parce qu’elle a \u00e9t\u00e9 intialis\u00e9e de cette mani\u00e8re, ou parce que cette valeur lui est attribu\u00e9e \u00e0 un endroit donn\u00e9 de l’algorithme. Par exemple :<\/p>\n

DECLARE\r\n   name v_periodo varchar(10) := ''<\/pre>\n
Le probl\u00e8me est que:<\/p>\n
    \n
  1. Oracle traite une cha\u00eene vide comme une valeur NULL. Donc \u00e0 la suite du traitement pr\u00e9c\u00e9dent, notre variable ne comporte pas<\/strong> une cha\u00eene vide, mais une valeur NULL.<\/li>\n
  2. Oracle effectue la diff\u00e9rence entre une cha\u00ecne vide et une cha\u00eene de valeur NULL. Donc le test<\/li>\n<\/ol>\n
    IF v_periodo = ''<\/pre>\n
    retourne false<\/strong> dans notre cas, puisque v_periodo ne comporte pas<\/strong> une cha\u00eene vide, mais une valeur NULL. Le traitement correct est :<\/p>\n
    IF v_periodo IS NULL<\/pre>\n
    Nous avons l\u00e0 un bel exemple de ‘bad practice’ de programmation qui conduira tr\u00e8s certainement \u00e0 un bug logique dans l’application, puisque la condition test\u00e9e (cha\u00eene vide) ne sera jamais possible, et donc le traitement correspondant ne sera jamais effectu\u00e9.<\/p>\n
    Et bien s\u00fbr, comme si cela ne suffisait pas, nous retrouvons ce bug dupliqu\u00e9 quelques lignes plus bas : \"RuleNULL2\"<\/a><\/p>\n
    Je pense qu’il doit exister quelque part un th\u00e9or\u00e8me informatique ou une variante quelconque de la loi de Murphy qui \u00e9dicte que le nombre de Copier-Coller d’une instruction incorrecte est proportionnel \u00e0 la dangerosit\u00e9 du bug qu’il induit.<\/p>\n
    Les deux autres violations de type ‘Blocker’ sont assez claires et il suffit d’ailleurs de jeter un coup d’oeil sur la documentation de SonarQube pour comprendre quelle est l’erreur et quelle est sa cons\u00e9quence :<\/p>\n
    \"RuleTrigger1\"<\/a><\/p>\n
    Une instruction COMMIT ou ROLLBACK au sein d’un trigger conduira \u00e0 une erreur ORA-04902. Il est n\u00e9cessaire d’utiliser une PRAGMA (directive de compilation) afin de d\u00e9clarer une transaction ind\u00e9pendate pour cette manipulation. Cela dit, j’ai tendance \u00e0 questionner tout instruction de type DML (Data Manipulation Language) au sein d’un trigger.<\/p>\n
    \"RuleBlocker3\"<\/a><\/p>\n
    Une variable a \u00e9t\u00e9 d\u00e9clar\u00e9e deux fois, ce qui conduira \u00e0 une erreur Oracle PLS-03371. J’appr\u00e9cie tout particuli\u00e8rement que SonarQube nous indique les 2 lignes o\u00f9 cette instruction est dupliqu\u00e9e car c’est une des plus difficiles \u00e0 investiguer, notamment dans un programme comme celui-ci qui comporte plusieurs dizaines de milliers de ligne. C’est fr\u00e9quent dans les vieilles applications PL\/SQL ‘Legacy’.<\/p>\n
    Que pouvons-nous dire de ces 3 r\u00e9gles ‘Blockers’ ?<\/p>\n
    Tout d’abord que leur niveau de gravit\u00e9 se justifie compl\u00e8tement :<\/p>\n