Le langage Scala apporte, entre autres, un système de type robuste permettant au compilateur de vérifier pas mal de choses pour nous. D’autres par les outils de qualité de code se focalisent d’une manière générale sur la syntaxe du code (indentation, espace, redondance des chaînes String, etc…).

La librairie WartRemover se focalise sur la robustesse du code Scala écrit. C’est à dire qu’elle va s’attacher à vérifier la cohérence des types retournés par les fonctions, ainsi que les fonctionnalités du langage présentant un potentiel risque d’erreur au runtime.

Un ensemble de règles sont fournies de base, voici quelques exemples :

  • Any, Nothing, Product : ces règles vont vérifier la cohérence du type renvoyé dans le cas d’une fonction ou d’un bloc de code. Au moment de l’inférence de type lors de la compilation, le compilateur, dans certains cas, utilise des types généralistes. L’utilisation de ces types laisse le système de type ouvert et laisse place à de potentielle erreur. Dans ce cas-là, il faut aider le compilateur, donnant plus de précision sur les intentions en matière de typage.
  • MutableDataStructures, Var : ces règles permettent de garantir que notre code n’est pas mutable.
  • Throw : cette règle permet d’interdire l’utilisation d’exception (qui est d’ailleurs une mauvaise pratique en FP)
  • TraversableOps : cette va vérifier la manière d’utiliser les l’API défini par le type Traversable. Elle va lever une erreur lors de l’utilisation de head, tail, last, etc.. Cette règle peut paraître étrange car ces fonctions sont bien utiles et sont une des valeurs ajoutées du langage. La raison est que ces fonctions sont susceptibles de lever une erreur dans certains cas.

Nous venons de voir un petit aperçu des règles disponibles ‘out of the box’. Il est possible d’écrire ses propres règles. Toutes les règles ne sont pas nécessairement bonnes à prendre, il faut garder un oeil critique et contextuel au projet.

Dans un projet, sous SBT, WartRemover vient comme un plugin et se lance lors de la phase de compilation, ce qui permet d’appliquer les règles systématiques et de s’assurer qu’il n’y aura pas de `tour dans la raquette un moment donné.

Il est intéressant d’intégrer ce type de librairie au démarrage du projet pour que les règles soient appliquées dès le début. En l’intégrant sur une base de code existante, on s’expose à des refactorings pouvant être compliqué.

Dans le cas de notre projet actuel, nous avons dû renoncer (temporairement) à certaine règle (temps / risque).

En conclusion, WartRemover permet d’écrire du code robuste et également de faire converger les développeurs vers des bonnes pratiques en terme de déclaration des types.

Wartremover