Analyse PL/SQL avec SonarQube – Blockers

PLSQL_BlockersCriticalDans le post précédent, nous avons créé notre propre Quality Profile PL/SQL en activant toutes les règles existantes dans SonarQube, au nombre de 132. Puis nous avons ensuite relancé l’analyse créée précédemment.

Nous allons ainsi pouvoir travailler avec l’ensemble des règles du Quality Profile par défaut de SonarQube et sélectionner celles qui nous intéressent afin de créer un tableau de bord ‘PL/SQL’ pour notre environnement de démo.

Les règles de type Blocker

Blockers

Nous pouvons constater tout d’abord 16 défauts concernant la règle ‘Use IS NULL and IS NOT NULL instead of direct NULL comparisons’. De quoi s’agit-il ?

RuleNULLUn drill-down depuis cette liste de défauts et SonarQube nous permet d’accéder au code incriminé.

Nous pouvons voir que le programmeur effectue un test sur la variable ‘v_periodo’ afin de vérifier si celle-ci est une chaîne (de caractères) vide, parce qu’elle a été intialisée de cette manière, ou parce que cette valeur lui est attribuée à un endroit donné de l’algorithme. Par exemple :

DECLARE
   name v_periodo varchar(10) := ''

Le problème est que:

  1. Oracle traite une chaîne vide comme une valeur NULL. Donc à la suite du traitement précédent, notre variable ne comporte pas une chaîne vide, mais une valeur NULL.
  2. Oracle effectue la différence entre une chaìne vide et une chaîne de valeur NULL. Donc le test
IF v_periodo = ''

retourne false dans notre cas, puisque v_periodo ne comporte pas une chaîne vide, mais une valeur NULL. Le traitement correct est :

IF v_periodo IS NULL

Nous avons là un bel exemple de ‘bad practice’ de programmation qui conduira très certainement à un bug logique dans l’application, puisque la condition testée (chaîne vide) ne sera jamais possible, et donc le traitement correspondant ne sera jamais effectué.

Et bien sûr, comme si cela ne suffisait pas, nous retrouvons ce bug dupliqué quelques lignes plus bas : RuleNULL2

Je pense qu’il doit exister quelque part un théorème informatique ou une variante quelconque de la loi de Murphy qui édicte que le nombre de Copier-Coller d’une instruction incorrecte est proportionnel à la dangerosité du bug qu’il induit.

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équence :

RuleTrigger1

Une instruction COMMIT ou ROLLBACK au sein d’un trigger conduira à une erreur ORA-04902. Il est nécessaire d’utiliser une PRAGMA (directive de compilation) afin de déclarer une transaction indépendate pour cette manipulation. Cela dit, j’ai tendance à questionner tout instruction de type DML (Data Manipulation Language) au sein d’un trigger.

RuleBlocker3

Une variable a été déclarée deux fois, ce qui conduira à une erreur Oracle PLS-03371. J’apprécie tout particulièrement que SonarQube nous indique les 2 lignes où cette instruction est dupliquée car c’est une des plus difficiles à investiguer, notamment dans un programme comme celui-ci qui comporte plusieurs dizaines de milliers de ligne. C’est fréquent dans les vieilles applications PL/SQL ‘Legacy’.

Que pouvons-nous dire de ces 3 régles ‘Blockers’ ?

Tout d’abord que leur niveau de gravité se justifie complètement :

  • dans le premier cas, une ‘malpractice’ de programmation conduit à une erreur logique et un bug très possible,
  • et les deux cas suivants sont des bugs qui feront tomber l’application.

Il s’agit donc de trois règles pour lesquelles aucune violation ne sera permise : tolérance zéro, ces défauts doivent être corrigés immédiatement.

Seconde constatation : ces règles sont connues, si on en juge par le faible nombre de cas rencontrés. Néanmoins, on peut jamais éviter :

  • Une personne nouvelle dans l’équipe, éventuellement débutante, mais qui en tout cas ne connaît pas la ‘best practice’ correspondante. Je parie que c’est le cas de la première règle (utiliser NULL / NOT NULL exclusivement), avec un même programmeur qui a utilisé une syntaxe incorrecte et l’a ensuite copiée-collée un peu partout.
  • Même lorsque chacun connaît la règle en question, une erreur d’inattention ou un oubli momentané reste possible.

Il est facile d’oublier de déclarer une transaction ou qu’une variable a déjà été déclarée quelques dizaines (voire centaines) de lignes plus haut. Heureusement, le plugin PL/SQL de SonarQube nous permet de vérifier et corriger ces fautes d’attention simplement et rapidement. J’apprécie tout particulièrement de pouvoir descendre jusqu’à la ligne de code où se trouve la violation, valider celle-ci et décider d’une remédiation immédiate.

Dans le prochain post, nous aborderons les défauts de type ‘Critical’. Bonne semaine !

Ce article est également disponible en Leer este articulo en castellano et Read that post in english.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *