En fait, si vous écrivez dans un langage moderne, alors, sans même le savoir, vous le passez à travers un analyseur statique. Le fait est que tout compilateur moderne fournit un petit ensemble d'avertissements sur les problèmes potentiels dans le code. Par exemple, en compilant du code C ++ dans Visual Studio, vous pouvez voir ce qui suit:
Dans cette sortie, nous voyons que la variable var n'a jamais été utilisée nulle part dans la fonction. Donc en fait, vous avez presque toujours utilisé un simple analyseur de code statique. Cependant, contrairement aux analyseurs professionnels tels que Coverity, Klocwork ou PVS-Studio, les avertissements fournis par le compilateur ne peuvent indiquer qu'une petite gamme de problèmes.
Si vous ne savez pas avec certitude ce qu'est l'analyse statique et comment l'implémenter, lisez cet article pour en savoir plus sur cette méthodologie.
Pourquoi une analyse statique est-elle nécessaire?
En un mot: accélération et simplification.
L'analyse statique vous permet de trouver un grand nombre de problèmes différents dans votre code: de l'utilisation abusive des constructions de langage aux fautes de frappe. Par exemple, au lieu de
auto x = obj.x;
auto y = obj.y;
auto z = obj.z;
Vous avez écrit le code suivant:
auto x = obj.x;
auto y = obj.y;
auto z = obj.y;
Comme vous pouvez le voir, il y a une faute de frappe sur la dernière ligne. Par exemple, PVS-Studio émet l'avertissement suivant:
V537 Envisagez de vérifier l'exactitude de l'utilisation de l'élément «y».
Si vous voulez mettre la main sur cette erreur, essayez un exemple prêt à l'emploi sur l'Explorateur du compilateur: * cliquez sur *.
Et comme vous le comprenez, il n'est pas toujours possible de prêter attention à ces parties du code tout de suite et à cause de cela, vous pouvez vous asseoir pour le débogage pendant une bonne heure, en vous demandant pourquoi tout fonctionne si étrangement.
Cependant, c'est une erreur évidente. Et si le développeur écrivait un code sous-optimal en raison du fait qu'il avait oublié une certaine subtilité du langage? Ou même autorisé un comportement indéfini dans le code? Malheureusement, de tels cas sont tout à fait courants et la majeure partie du temps est consacrée au débogage de code de travail spécifique contenant des fautes de frappe, des erreurs typiques ou un comportement non défini.
C'est pour ces situations que l'analyse statique est apparue. Il s'agit d'un assistant pour le développeur qui signalera divers problèmes dans le code et expliquera dans la documentation pourquoi il n'est pas nécessaire d'écrire de cette façon, à quoi cela peut conduire et comment le résoudre. Voici un exemple de son apparence: * cliquez sur *.
Vous pouvez trouver des erreurs plus intéressantes que l'analyseur peut détecter dans les articles:
- Top 10 des erreurs dans les projets C ++ en 2019
- Top 10 des erreurs dans les projets C # de 2019
- Top 10 des bogues dans les projets Java de 2019
Maintenant, après avoir lu ce matériel et convaincu de l'utilité de l'analyse statique, vous voudrez peut-être le mettre à l'épreuve. Mais par où commencer? Comment intégrer un nouvel outil dans un projet en cours? Et comment lui présenter l'équipe? Vous trouverez ci-dessous des réponses à ces questions.
Remarque. L'analyse statique ne remplace ni n'annule une chose aussi utile que les révisions de code. Il complète ce processus en aidant à remarquer et à corriger les fautes de frappe, les inexactitudes et les constructions dangereuses à l'avance. Il est beaucoup plus productif de se concentrer sur les algorithmes et la compréhensibilité du code lors de la révision du code, plutôt que de rechercher les mauvaises parenthèses ou de lire des fonctions de comparaison ennuyeuses .
0. Apprendre à connaître l'instrument
Tout commence par une version d'essai. En effet, il est difficile de décider d'implémenter quelque chose dans le processus de développement si vous n'avez jamais vu l'outil en direct auparavant. Par conséquent, la première étape consiste à télécharger la version d'essai .
Ce que vous apprendrez à ce stade:
- Quelles sont les manières d'interagir avec l'analyseur;
- L'analyseur est-il compatible avec votre environnement de développement;
- Quels problèmes y a-t-il actuellement dans vos projets.
Après avoir installé tout ce dont vous avez besoin, la première étape consiste à exécuter une analyse de l'ensemble du projet ( Windows , Linux , macOS ). Dans le cas de PVS-Studio dans Visual Studio, vous verrez une image similaire:
le fait est que les analyseurs statiques émettent généralement un grand nombre d'avertissements pour les projets avec une grande base de code. Il n'est pas nécessaire de tous les résoudre, car votre projet fonctionne déjà, ce qui signifie que ces problèmes ne sont pas critiques. Cependant, vous pouvez consulter les avertissements les plus intéressantset réparez-les si nécessaire. Pour ce faire, vous devez filtrer la sortie et ne laisser que les messages les plus fiables. Dans le plugin PVS-Studio pour Visual Studio, cela se fait en filtrant par niveaux d'erreur et catégories. Pour la sortie la plus précise, ne laissez que Haut et Général activés :
En effet, 178 avertissements sont beaucoup plus faciles à visualiser que quelques milliers ... Les bons avertissements se trouvent souvent dans les
onglets Moyen et Faible , mais ces catégories incluent les diagnostics qui ont une précision inférieure (fiabilité). Plus d'informations sur les niveaux d'avertissement et les options pour travailler sous Windows peuvent être trouvées ici: * cliquez *.
Après avoir examiné avec succès les erreurs les plus intéressantes (et les avoir corrigées avec succès), il vaut la peine de supprimer les avertissements restants . Cela permet de garantir que les nouveaux avertissements ne sont pas perdus parmi les anciens. De plus, un analyseur statique est un assistant de programmeur, pas une liste de bogues. :)
1. Automatisation
Après la réunion, il est temps de configurer les plugins et de les intégrer dans CI. Cela doit être fait avant que les programmeurs ne commencent à utiliser l'analyseur statique. Le fait est qu'un programmeur peut oublier d'activer l'analyse ou ne pas vouloir du tout. Pour ce faire, vous devez effectuer une dernière vérification de tout, afin que le code non vérifié ne puisse pas entrer dans la branche de développement général.
Ce que vous apprendrez à ce stade:
- Quelles options d'automatisation l'outil fournit-il;
- L'analyseur est-il compatible avec votre système de construction?
Puisqu'il n'y a pas de documentation parfaite, vous devez parfois écrire pour le support . C'est normal et nous sommes heureux de vous aider. :)
Passons maintenant aux services d'intégration continue (CI). Tout analyseur peut y être intégré sans problème majeur. Pour ce faire, vous devez créer une étape distincte dans le pipeline, qui se trouve généralement après l'assemblage et les tests unitaires. Cela se fait à l'aide de divers utilitaires de console. Par exemple, PVS-Studio fournit les utilitaires suivants:
- PVS-Studio_Cmd.exe (analyse de solutions, projets C #, C ++ sous Windows)
- CLMonitor.exe (surveillance de la compilation)
- pvs-studio-analyzer (analyse de projets C ++ sous Linux / macOS)
- pvs-studio-dotnet (analyse de solutions, projets C # sous Linux / macOS)
- pvs-studio.jar (analyse de projets Java)
- PlogConverter (convertisseur de fichier journal)
Pour intégrer l'analyse dans CI, vous devez faire trois choses:
- Installez l'analyseur;
- Lancer l'analyse;
- Donner des résultats.
Par exemple, pour installer PVS-Studio sur Linux (base Debian), vous devez exécuter les commandes suivantes:
wget -q -O - https://files.viva64.com/etc/pubkey.txt \
| sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list \
https://files.viva64.com/etc/viva64.list
sudo apt-get update -qq
sudo apt-get install -qq pvs-studio
Sur les systèmes Windows, il n'est pas possible d'installer l'analyseur à partir du gestionnaire de packages, mais il est possible de déployer l'analyseur à partir de la ligne de commande:
PVS-Studio_setup.exe /verysilent /suppressmsgboxes
/norestart /nocloseapplications
Vous pouvez en savoir plus sur le déploiement de PVS-Studio sur les systèmes Windows * ici *.
Après l'installation, vous devez exécuter l'analyse directement. Cependant, il est recommandé de ne le faire qu'une fois la compilation et les tests réussis. En effet, l'analyse statique prend généralement deux fois plus de temps que la compilation.
Étant donné que la méthode de lancement dépend de la plate-forme et des spécificités du projet, je vais montrer l'option C ++ (Linux) à titre d'exemple:
pvs-studio-analyzer analyze -j8 \
-o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -w
La première commande analysera, et la seconde convertira le rapport au format texte, l'affichera à l'écran et retournera un code retour autre que 0 en cas d'avertissement. Un mécanisme similaire est utile pour bloquer un assembly en présence de messages d'erreur. Cependant, vous pouvez toujours supprimer l'indicateur -w et ne pas bloquer l'assemblage contenant les avertissements.
Remarque. Le format du texte n'est pas pratique. Ce n'est qu'un exemple. Faites attention au format de rapport le plus intéressant - FullHtml. Il vous permet de naviguer dans votre code.
Vous pouvez en savoir plus sur la configuration de l'analyse sur CI dans l'article " PVS-Studio et intégration continue " (Windows) ou " Comment configurer PVS-Studio dans Travis CI"(Linux).
D'accord, vous avez configuré l'analyseur sur le serveur de compilation. Maintenant, si quelqu'un a téléchargé du code non vérifié, l'étape de vérification tombera et vous pourrez trouver le problème, mais ce n'est pas très pratique, car il est plus efficace de vérifier le projet pas après comment les branches ont été fusionnées, et avant cela, au stade de la demande d'extraction.
En général, la configuration de l'analyse d'une demande d'extraction ne diffère pas beaucoup du lancement habituel de l'analyse sur CI. Sauf pour la nécessité d'obtenir une liste des fichiers modifiés. Habituellement, ils peuvent être obtenus en demandant la différence entre les branches en utilisant git:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
Vous devez maintenant transmettre cette liste de fichiers à l'analyseur. Par exemple, dans PVS-Studio, ceci est implémenté en utilisant l'indicateur -S :
pvs-studio-analyzer analyze -j8 \
-o PVS-Studio.log \
-S .pvs-pr.list
Vous pouvez en savoir plus sur l'analyse des pull requests * ici *. Même si votre CI ne figure pas dans la liste des services spécifiés dans l'article, la section générale sur la théorie de ce type d'analyse vous sera utile.
En configurant l'analyse des pull requests, vous pouvez bloquer les validations contenant des avertissements, créant ainsi une limite que le code non vérifié ne peut pas franchir.
Tout cela est bien beau, mais j'aimerais pouvoir afficher tous les avertissements en un seul endroit. Non seulement à partir d'un analyseur statique, mais également à partir de tests unitaires ou d'un analyseur dynamique. Il existe différents services et plugins pour cela. PVS-Studio, par exemple, dispose d'un plugin pour l'intégration dans SonarQube .
2. Intégration sur les machines des développeurs
Il est maintenant temps d'installer et de configurer l'analyseur pour une utilisation quotidienne en développement. À ce stade, vous vous êtes déjà familiarisé avec la plupart des méthodes de travail, ce qui peut être appelé la partie la plus simple.
Comme option la plus simple, les développeurs peuvent installer eux-mêmes l'analyseur requis. Cependant, cela prendra beaucoup de temps et les distraira du développement, vous pouvez donc automatiser ce processus à l'aide du programme d'installation et des indicateurs nécessaires. Il existe différents indicateurs pour PVS-Studio pour une installation automatisée . Cependant, il existe toujours des gestionnaires de paquets comme Chocolatey (Windows), Homebrew (macOS) ou des dizaines d'options pour Linux.
Ensuite, vous devrez installer les plugins nécessaires, par exemple pour Visual Studio , IDEA ,Cavalier etc.
3. Utilisation quotidienne
À ce stade, il est temps de dire quelques mots sur les moyens d'accélérer les performances de l'analyseur au quotidien. Une analyse complète de l'ensemble du projet prend beaucoup de temps, mais à quelle fréquence modifions-nous le code en même temps dans l'ensemble du projet? Il n'y a guère de refactoring à une telle échelle qu'il affectera immédiatement l'ensemble de la base de code. Le nombre de fichiers modifiés à la fois dépasse rarement dix, il est donc logique de les analyser. Pour une telle situation, il existe un mode d'analyse incrémentale . Ne vous inquiétez pas, ce n'est pas un autre outil. C'est un mode spécial qui vous permet d'analyser uniquement les fichiers modifiés et leurs dépendances, et cela se produit automatiquement après la construction, si vous travaillez dans l'EDI avec le plugin installé.
Si l'analyseur détecte des problèmes dans le code récemment modifié, il le signalera de lui-même. Par exemple, PVS-Studio vous en informera au moyen d'une notification: il
va sans dire qu'il ne suffit pas de dire aux développeurs d'utiliser l'outil. Nous devons leur dire d'une manière ou d'une autre ce que c'est et comment c'est. Par exemple, voici des articles sur le démarrage rapide de PVS-Studio, mais vous pouvez trouver des tutoriels similaires pour n'importe quel outil que vous préférez:
- Comment exécuter PVS-Studio sous Windows (C, C ++, C #)
- Comment exécuter PVS-Studio sur Linux et macOS (C, C ++)
- Comment démarrer PVS-Studio Java
Ces articles fournissent toutes les informations nécessaires à un usage quotidien et ne prennent pas beaucoup de temps. :)
Même au stade de la connaissance de l'outil, nous avons supprimé de nombreux avertissements lors de l'un des premiers lancements. Hélas, les analyseurs statiques ne sont pas idéaux, ils donnent donc de temps en temps des faux positifs. Il est généralement facile de les supprimer, par exemple, dans le plugin PVS-Studio pour Visual Studio, il suffit de cliquer sur un bouton:
Cependant, vous ne pouvez pas seulement les supprimer. Par exemple, vous pouvez signaler un problème au support. S'il est possible de corriger les faux positifs, vous remarquerez peut-être que dans les futures mises à jour, il y aura de moins en moins de faux positifs spécifiques à votre base de code.
Après intégration
Nous sommes donc passés par toutes les étapes d'intégration de l'analyse statique dans le processus de développement. Malgré l'importance de mettre en place de tels outils dans CI, le point de départ le plus important est l'ordinateur du développeur. Après tout, un analyseur statique n'est pas un juge qui dit quelque part loin de vous que le code est sans valeur. Au contraire, c'est un assistant qui vous avertit si vous êtes fatigué et vous rappelle si vous avez oublié quelque chose.
Cependant, sans une utilisation régulière, il est peu probable que l'analyse statique simplifie considérablement le développement. Après tout, son avantage le plus important pour le développeur ne réside pas tant dans la recherche de sections de code complexes et controversées, mais dans leur détection précoce. Convenez qu'il est non seulement désagréable, mais aussi très long de trouver le problème lorsque les modifications ont été testées. L'analyse statique, lorsqu'elle est utilisée régulièrement, examine chaque changement directement sur votre ordinateur et signale les endroits suspects lorsque vous travaillez sur le code.
Et si vous ou vos collègues ne savez toujours pas si cela vaut la peine d'implémenter l'analyseur, je vous suggère de lire l'article " Raisons d' implémenter l' analyseur de code statique PVS-Studio dans le processus de développement". Cela répond aux préoccupations typiques des développeurs selon lesquelles l'analyse statique prendra leur temps, et ainsi de suite.
Si vous souhaitez partager cet article avec un public anglophone, veuillez utiliser le lien de traduction: Maxim Zvyagintsev. Analyse statique: de la mise en route à l'intégration .