Langage de programmation Java : trouver zéro erreur avec l’analyse statique

Les nouveaux projets apportent de nouveaux défis et de nouvelles connaissances. Dans mon projet actuel J’ai récemment créé une définition pour gérer les vérifications nulles dans l’analyse de code statique. Il était important pour beaucoup dans le projet que les paramètres ne soient pas seulement utilisés lors de l’exécution, par exemple Objects.requireNonNull(…)) sont vérifiés, mais aussi directement lors de la compilation. Par conséquent, nous avons décidé d’utiliser également l’analyse de code statique pour vérifier la gestion null mettre.

Analyse de code statique

Avant de nous plonger dans les bibliothèques d’annotation et de vérificateur décalées qui existent pour Java, permettez-moi d’expliquer brièvement en quoi consiste l’analyse de code statique. Ici, le code du programme est vérifié par l’outillage lors de la compilation. L’outil actuellement le plus courant en Java est certainement SpotBugs, qui peut être intégré dans des builds avec Maven ou Gradle et dont les résultats peuvent également être publiés automatiquement sur des plateformes telles que SonarCloud. Avec une analyse de code statique, vous pouvez trouver des problèmes comme un débordement de mémoire, une boucle infinie ou des erreurs “Out of Bound”. Un exemple simple est une division par 0. Si quelque chose comme cela se produit dans le code, l’analyse peut fournir un avertissement ou , selon la configuration, la construction complète avec des erreurs Dans notre projet, nous avons une telle vérification dans GitHub Actions, qui place les résultats directement dans SonarCloud et une pull request.

La bonne gestion de null

Un problème avec la programmation avec Java est certainement lié à null. Personnellement, je suis d’avis que null a sa justification, bien que Tony Hoare, l’inventeur de la référence nulle en programmation, en parle maintenant comme d’une “erreur d’un billion de dollars”.

Cependant, en Java, il n’existe aucun moyen natif de définir si un paramètre peut être nul. Entre-temps, des tentatives ont été faites pour résoudre ce problème en utilisant divers moyens dans la bibliothèque de classes. des exemples pour cela sont java.util.Optional, Objects.requireNonNull(…) ou JSR305.

Kotlin est un bon exemple de langage de programmation prenant en charge nativement les références nulles. Il fait explicitement la distinction entre les références nullables et les références non null. Ce dernier est la valeur par défaut, bien qu’une variable avec une telle référence ne puisse jamais être affectée de null. Si vous avez besoin d’une variable qui peut contenir null, vous devez travailler avec une référence nullable. Ce sera à peu près ça ? caractères spécifiés. Le code suivant inclut un exemple Kotlin pour les deux références :

var a: String = "abc" // Regular initialization means
                      // non-null by default
a = null // compilation error

var b: String? = "abc" // can be set to null
b = null // ok

Puisqu’il n’y a pas de support natif de ce type dans Java, des tentatives sont faites pour l’intégrer au mieux en utilisant l’analyse de code statique. En général, deux annotations sont nécessaires ici, avec une (@Nullable) définit qu’une valeur ou une variable peut être nulle, et l’autre annotation définit qu’une valeur ou une variable ne doit jamais être nulle (@NonNull).

Un exemple de code qui définit une méthode et ajoute les informations via une annotation que la valeur de retour de la méthode n’a jamais null peut être:

@NonNull String getName() {
    if(isUnique()) {
        return „Item „ + getId();
    } else {
        return null;
    }
}

Comme vous pouvez le voir dans la mise en œuvre de la méthode, il est tout à fait possible qu’elle null Retour. Ce serait un cas où l’analyse statique du code révèle une violation. Par exemple, si vous le souhaitez, vous pouvez configurer IntelliJ pour afficher directement ces problèmes.

Le code suivant que le @Nullable L’annotation utilisée entraîne un avertissement dans l’analyse :

void check(@Nullable String value) {
    Objects.hash(value.toLowerCase());
}

Dans cet exemple, l’annotation @Nullable pour la variable value définit qu’il s’agit de la valeur null puis-je avoir. Cependant, le fait que le code accède directement à la variable conduit potentiellement à un NullPointerException lors de l’exécution. Cela serait également évalué par l’analyse de code statique et signalé comme un problème.

Installation dans votre propre projet

Si vous souhaitez intégrer une telle analyse de code statique dans votre propre projet, vous devez créer quelques exigences simples. La première chose à faire est de choisir un ou plusieurs outils d’analyse. Ici je recommande Spotbugs, qui est le successeur de Findbugs. L’outil peut être démarré à partir de la ligne de commande ou intégré dans une version Gradle ou Maven. Afin d’analyser les problèmes trouvés, vous pouvez soit les consulter dans le propre client swing de Spotbug, soit, par exemple, sous forme d’aperçu HTML dans le cadre d’un site Maven généré à l’aide de Maven. site-Cible. Vous pouvez configurer l’outil pour qu’il télécharge les résultats vers un sonar ou le SonarCloud, par exemple.

Wer @Nullable– et @NonNull– souhaitez utiliser des annotations dans le projet nécessite une bibliothèque qui fournit l’annotation. Votre propre projet ne doit dépendre de la bibliothèque qu’au moment de la compilation. Ici aussi, il existe (malheureusement) toute une gamme de bibliothèques qui fournissent des annotations. L’examen de chaque bibliothèque en fonction de ses avantages et de ses inconvénients fera partie d’un article distinct. Par conséquent, je recommande d’abord les annotations de Spotbug en tant que dépendance, qui se trouvent aux coordonnées Maven suivantes :

    com.github.spotbugs
    spotbugs-annotations
    4.7.3
 

Malheureusement, l’abondance d’outils et de bibliothèques ne permet pas de trouver facilement la combinaison parfaite et tournée vers l’avenir. En approfondissant le sujet, j’ai été choqué de constater que beaucoup de choses dans ce domaine ne sont toujours pas définies par des normes ou des meilleures pratiques couramment utilisées. Bien qu’il y ait eu différentes approches comme avec leJSR305, mais ceux-ci ont toujours échoué à un moment donné et sont parfois utilisés dans un mélange sauvage aujourd’hui. C’est pourquoi je consacrerai un article séparé à ce problème dans un avenir proche.

(rme)