Quels sont les avantages réels de l'analyse de code statique?

Des outils comme pc-lint ou QAC peuvent être utilisés pour effectuer une analyse de code statique sur une base de code.

D'après mon expérience, l'analyse statique génère souvent une énorme quantité de bruit, c'est-à-dire des avertissements sur des choses qui ne sont pas de vrais bugs mais qui enfreignent d'une manière ou d'une autre l'une des règles d'un ensemble de règles donné. La désactivation de certaines règles (pour de bon dans l'ensemble de règles ou via des commentaires spéciaux dans le code) peut être un processus lourd.

Quels sont les avantages réels de l'analyse de code statique?

J'ai travaillé dans un endroit qui utilisait un système d'analyse de code statique commercial appelé Coverity Prevent, et c'était vraiment incroyable! C'est vraiment sophistiqué et intelligent.

Nous y avons jeté environ 18 Go de code C et C ++ open source et propriétaire, et il tracerait les chemins de code et trouverait rapidement des bogues subtils qui prendraient une éternité humaine à traquer. Il était également excellent pour identifier des choses qui seraient généralement des Heisenbugs.

Il fonctionnait tous les quelques jours contre notre base de code, et une fonctionnalité intéressante était que nous pouvions lui dire: «Ce n'est pas vraiment un bogue», et il s'en souviendrait à l'avenir.

Le truc c'est que la Coverity est vraiment chère. Ils ne publient pas les coûts, mais j'ai l'impression que pour les projets commerciaux, cela commence par des centaines de milliers de dollars par an. Mais cela nous a probablement évité d'avoir à embaucher tout un tas de développeurs et de personnel d'assurance qualité, donc dans l'ensemble, notre direction semblait penser que c'était un bon achat.

Ayant eu cette expérience, je regarde très favorablement l'analyse de code statique.

Lorsque vous commencez avec une nouvelle langue, c'est bien d'avoir un coach. Voilà comment je pense aux outils d'analyse statique. J'écris beaucoup de javascript et au début j'ai repris quelques mauvaises habitudes principalement parce que je transférais certaines choses des langues antérieures. Javascript est assez flexible, vous pouvez donc vous en sortir avec à peu près n'importe quoi, mais si jslint m'avait averti de certains modèles, j'aurais choisi de meilleurs modèles de codage dès le début au lieu d'avoir à réapprendre des choses plus tard.

Les analyseurs statiques sont essentiellement des revues de code assistées par machine. Ils indiqueront les zones douteuses qui pourraient être manquées lors des tests réguliers.

Par exemple, l'auteur voulait-il vraiment faire une cession dans cette condition?

if (x = 1) {
    ...
}

Ou peut-être qu'une recrue confond le casting lexical:

char* number = "123";
int converted = number;

Les analyseurs statiques nécessitent certainement des ajustements. Là encore, le contrôle des révisions, les wikis, les suiveurs de bogues, les jolies imprimantes et d'autres outils nécessitent également une configuration. Plus le projet est gros, meilleure est la récompense du travail initial.

Du point de vue d'un consultant, chaque outil d'analyse statique aura du bruit mais tous les analyseurs statiques ne sont pas créés égaux. Les outils d'analyse statique comme Coverity, Klocwork, Grammatech ont de bonnes techniques d'analyse qui devraient produire des résultats plus précis. Si vous ajustez et ajustez un peu plus, vous obtenez généralement de meilleurs résultats (après tout, les analyseurs statiques doivent pouvoir fonctionner sur tous les différents types de code, d'un petit appareil médical à un système d'exploitation réseau). La définition du «bruit» dépend également de vos critères pour ce qui constitue un rapport digne de correction. À une extrémité du spectre, certains développeurs marquent tous les rapports qu'ils ne corrigent pas comme "faux" (même du code mal écrit qu'ils n'ont pas le temps de corriger) et à l'autre extrémité,

Certains de ces outils sont plus centrés sur l'analyse centrale et d'autres sur le bureau, bien que les trois aient des fonctionnalités qui prennent en charge les deux. Comme @Bob l'a mentionné, ils coûtent de l'argent.

Dans ma précédente entreprise, nous avons utilisé l'analyseur statique de Parasoft. Et on croyait au sein de l'équipe qu'au moins 60% des bogues d'exécution ont été détectés avant la compilation.

L'analyse statique peut également être effectuée sans outils, en effectuant des révisions manuelles du code logiciel. C'est souvent le moyen le plus rentable d'améliorer la qualité du code.

La deuxième meilleure option consiste à investir dans un ou plusieurs outils d'analyse statique haut de gamme (comme Coverity ou KLOCwork). Étant donné que ces outils effectuent des analyses beaucoup plus profondes que les peluches, par exemple, le rapport signal / bruit est bien meilleur.

Je considère l'utilisation de la charpie comme troisième option, en raison du niveau de bruit élevé. Appliquer de la charpie sur un projet existant peut être une tâche intimidante.

D'une manière générale, l'analyse statique des programmes a beaucoup progressé ces dernières années. Les outils d'analyse statique actuels sont capables d'effectuer des analyses interprocédurales approfondies, et peuvent identifier automatiquement, par exemple, les pré et post-conditions de la procédure. Cela peut également être d'une grande aide pour les révisions de code ultérieures.

En raison du taux élevé de faux positifs, vous ne devez pas utiliser un outil d'analyse statique (comme lint ou FindBugs) pour chaque compilation.

C'est plutôt un bon test de santé mentale à consulter une fois que vous avez un bug et que vous ne pouvez pas le découvrir . Dans ce cas, vous pouvez connaître les faux positifs et vous avez peut-être déjà réduit les sources possibles de l'erreur. Par exemple, si vous reproduisez votre bogue sans même exécuter un module, vous pouvez ignorer ce que FindBugs dit pour eux. Cela est particulièrement utile lorsque vous regardez un morceau de code et pensez qu'il dit une chose, alors que le compilateur le lit littéralement (comme en Java lorsque vous avez une equalsméthode qui prend le type de la classe au lieu de Object).

Vous pouvez également faire en sorte que des outils d'analyse statique fassent partie de votre processus de développement: lorsqu'un développeur obtient une révision de code, il doit également exécuter FindBugs dessus. En bref, c'est utile, mais vous ne l'utiliserez pas aussi souvent que le compilateur ou l'éditeur de texte.