Nous nous félicitons de tout bavardage sur la qualité du code. Nos clients, étudiants et autres utilisateurs de tous les coins d'Internet nous écrivent. Quel que soit le pays, le fuseau horaire ou la langue. Eh bien, parler la langue, pas la programmation. Parmi les langages de programmation, nous nous sommes jusqu'à présent intéressés à un ensemble limité. En ce moment, c'est C, C ++, C # et Java. La communication présente de nombreux avantages. Nous mettons en œuvre immédiatement les suggestions de certains utilisateurs, car elles sont vraiment utiles. Souvent, nous donnons simplement un coup de main au projet de quelqu'un en expliquant les avertissements de l'analyseur, qui finissent par être des erreurs. Cette note concerne un tel cas.
À propos de l'analyseur
PVS-Studio est un outil conçu pour détecter les erreurs et les vulnérabilités potentielles dans le code source des programmes, écrit en C, C ++, C # et Java. Il fonctionne dans un environnement Windows, Linux et macOS.
Il existe trois formulaires de rétroaction pour nous contacter:
- Rétroaction
- Demande d'essai
- Demande de prix
Jeudi soir
Un utilisateur actif qui a essayé l'analyseur sur son code a activement commencé à envoyer de faux avertissements. Avant de pouvoir répondre, il y avait déjà 3 e-mails. C'était la fin de la journée de travail et j'étais fatigué (en parlant de la question de la fiabilité de la révision manuelle du code). Notre équipe se préparait activement à une sortie très aboutie, dans quelques jours.
J'ai décidé de répondre vendredi ou même la semaine prochaine:
Bonjour ConstantineNous examinerons vos avertissements. La semaine prochaine, je commenterai les endroits suspects :-)Cette note concerne l'efficacité de l'analyse de code statique. La révision manuelle du code sera inférieure à la vérification automatique dans de nombreux cas, surtout en fin de journée.
Avec la permission de l'utilisateur, je vais vous citer nos mails:
Courriel 1Avertissements V712 faussement positifs:uint32_t StartUpCounter = 0, HSEStatus = 0; RCC->CR |= ((uint32_t)RCC_CR_HSEON); { HSEStatus = RCC->CR & RCC_CR_HSERDY; StartUpCounter++; } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));
Courriel 2V715 faux positif pour le même fragment: {
Courriel 3Saints chats, un endroit tellement hanté! L'analyseur se plaint du même fragment (voir le code des courriels précédents):V560 Une partie de l'expression conditionnelle est toujours vraie: (StartUpCounter! = ((Uint16_t) 0x5000)). lpmode.cpp 356V776 Boucle potentiellement infinie. La variable dans la condition de sortie de boucle 'HSEStatus == 0' ne change pas sa valeur entre les itérations. lpmode.cpp 356Peut-être que je ne reçois pas quelque chose? Mais dans la pratique, tout fonctionne, et si le quartz ne démarre pas, alors nous quittons ce fragment sur timeout ;-)Courriel 4 (réponse)Bonjour ConstantineNous examinerons vos avertissements. La semaine prochaine, je commenterai les endroits suspects :-)Courriel 5Merde! Ce n'est qu'après votre e-mail, j'ai remarqué que la phrase "faire" est manquée ... Enfin, tout est tombé dans un sillon! On dirait que j'ai complètement perdu la netteté de mes yeux%)faire {...} tandis que (...);Conclusion
Comme vous l'avez peut-être remarqué, il y avait 4 avertissements d'analyseur pour le même fragment, mais il a quand même fallu du temps pour convaincre l'utilisateur qu'il y avait une erreur. Dans une telle situation, la révision manuelle n'aurait même aucune chance.
Une histoire similaire avec une fin heureuse: "
Comment PVS-Studio s'est avéré plus attentif que trois programmeurs et demi "
Utilisez des analyseurs statiques dans votre projet. Ils ne remplacent pas la révision du code par des collègues, mais ajoutent un support au contrôle de la qualité du code.