Notre direction a récemment discuté avec des vendeurs de C++. outils d'analyse statique . Bien sûr, les vendeurs disent qu'ils vont trouver des tonnes de bugs, mais je suis sceptique.
Comment ces outils fonctionnent-ils dans le monde réel ? Trouvent-ils de vrais bogues ? Permettent-ils aux programmeurs plus jeunes d'apprendre ?
En valent-ils la peine ?
L'analyse statique du code en vaut presque toujours la peine. Le problème avec une base de code existante est qu'elle signalera probablement beaucoup trop d'erreurs pour être utile dès le départ.
J'ai travaillé une fois sur un projet qui avait plus de 100 000 avertissements du compilateur... aucun intérêt à utiliser les outils Lint sur cette base de code.
Utiliser les outils Lint "correctement" signifie adhérer à un meilleur processus (ce qui est une bonne chose). L'un des meilleurs emplois que j'ai eu était dans un laboratoire de recherche où nous n'étions pas autorisés à vérifier le code avec des avertissements.
Donc, oui, les outils en valent la peine... à long terme. À court terme, mettez les avertissements de votre compilateur au maximum et voyez ce qu'il rapporte. Si le code est "propre", c'est le moment de regarder les outils de lint. Si le code a beaucoup d'avertissements... priorisez-les et corrigez-les. Une fois que le code n'a plus d'avertissements (ou du moins très peu), regardez les outils Lint.
Ainsi, les outils Lint ne vont pas aider une base de code médiocre, mais une fois que vous avez une bonne base de code, ils peuvent vous aider à la conserver.
Edit :
Dans le cas du produit de plus de 100 000 avertissements, il a été décomposé en environ 60 projets Visual Studio. Lorsque tous les avertissements ont été supprimés de chaque projet, ils ont été modifiés de manière à ce que les avertissements soient des erreurs, ce qui a empêché l'ajout de nouveaux avertissements aux projets qui avaient été nettoyés (ou plutôt, cela a permis à mon collègue d'engueuler à juste titre tout développeur qui vérifiait du code sans le compiler auparavant :-)
D'après mon expérience avec quelques employeurs, Coverity Prevent pour C/C++ en valait vraiment la peine, car il a permis de trouver quelques bogues même dans le code des bons développeurs, et beaucoup de bogues dans le code des pires développeurs. D'autres ont déjà abordé les aspects techniques, je vais donc me concentrer sur les difficultés politiques.
Tout d'abord, les développeurs dont le code a le plus besoin d'une analyse statique sont les moins susceptibles de l'utiliser volontairement. Je crains donc que vous n'ayez besoin d'un soutien fort de la part de la direction, en pratique comme en théorie ; sinon, l'analyse statique risque de n'être qu'un élément de la liste de contrôle, destiné à produire des mesures impressionnantes sans que les bogues soient réellement corrigés. N'importe quel outil d'analyse statique produira des faux positifs ; vous devrez probablement affecter quelqu'un à la réduction de leur nuisance, par exemple en triant les défauts, en donnant la priorité aux vérificateurs et en modifiant les paramètres. (Un outil commercial devrait être extrêmement performant pour ne jamais montrer un faux positif plus d'une fois ; cela peut valoir le prix à lui seul). Même les défauts authentiques sont susceptibles de générer de l'ennui ; mon conseil à ce sujet est de ne pas s'inquiéter, par exemple, des commentaires d'enregistrement qui se plaignent que les bogues manifestement destructeurs sont "mineurs".
Mon plus grand conseil est un corollaire de ma première loi, ci-dessus : Commencez par les coups bas, et regardez les bogues douloureusement évidents de vos pires développeurs. Certains d'entre eux pourraient même avoir été détectés par des avertissements du compilateur, mais beaucoup de bogues peuvent passer à travers les mailles du filet, par exemple lorsqu'ils sont supprimés par des options de ligne de commande. Les bogues vraiment flagrants peuvent être politiquement utiles, par exemple avec une liste des dix défauts les plus drôles, qui peut concentrer les esprits de façon merveilleuse, si elle est utilisée avec précaution.
Cela aide. Je vous suggère de prendre une version d'essai et de l'utiliser dans une partie de votre code source qui vous semble négligée. Ces outils génèrent beaucoup de faux positifs. Une fois que vous les aurez examinés, vous trouverez probablement un ou deux dépassements de tampon qui vous épargneront bien des soucis dans un avenir proche. De plus, essayez au moins deux ou trois variétés (ainsi que certains produits OpenSource).
Comme l'ont fait remarquer plusieurs personnes, si vous exécutez un outil d'analyse statique à fond sur la plupart des applications, vous obtiendrez beaucoup d'avertissements, dont certains peuvent être des faux positifs ou ne pas conduire à un défaut exploitable. C'est cette expérience qui conduit à la perception que ces types d'outils sont bruyants et peut-être une perte de temps. Cependant, certains avertissements mettent en évidence des défauts réels et potentiellement dangereux qui peuvent conduire à des problèmes de sécurité, de fiabilité ou d'exactitude. Pour de nombreuses équipes, ces problèmes sont importants à résoudre et peuvent être presque impossibles à découvrir par des tests.
Cela dit, les outils d'analyse statique peuvent être d'une grande utilité, mais leur application à une base de code existante requiert un peu de stratégie. Voici quelques conseils qui pourraient vous aider
1) N'activez pas tout en même temps, décidez d'un ensemble initial de défauts, activez ces analyses et corrigez-les dans l'ensemble de votre base de code.
2) Lorsque vous vous attaquez à une catégorie de défauts, aidez toute votre équipe de développement à comprendre ce qu'est le défaut, pourquoi il est important et comment coder pour se défendre contre ce défaut.
3) Travailler pour débarrasser complètement la base de code de cette catégorie de défauts.
4) Une fois que cette catégorie de problèmes aura été résolue, introduisez un mécanisme permettant de rester dans cet état de zéro problème. Heureusement, il est beaucoup plus facile de s'assurer que vous ne réintroduisez pas d'erreur si vous êtes dans un état de base sans erreur.
J'en ai utilisé - PC-Lint, par exemple, et ils ont trouvé certaines choses. En général, ils sont configurables et vous pouvez leur dire "arrêtez de m'embêter avec xyz", si vous déterminez que xyz n'est pas vraiment un problème.
Je ne sais pas s'ils aident les jeunes programmeurs à apprendre beaucoup, mais ils peuvent être utilisés comme un mécanisme pour aider à resserrer le code.
J'ai constaté qu'une deuxième série d'yeux (sceptiques, à la recherche de bogues) et les tests unitaires permettent généralement d'attraper plus de bogues.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
