Vous vous demandez sûrement quel code est le meilleur: un projet open source ou un projet fermé? Après avoir lu notre blog, vous pourriez penser que tous les bugs ont été collectés par des projets open source. Mais ce n’est pas le cas. Des erreurs sont présentes dans tous les projets, quelle que soit la manière dont elles sont stockées. Et la qualité sera meilleure là où elle sera améliorée. Ceci est une petite note sur la façon dont un bogue a été corrigé dans un projet pendant 2 ans, mais aurait pu le faire en 5 minutes.
Chronologie des événements
Minetest est un moteur de jeu multiplateforme open source contenant environ 200 000 lignes de code C, C ++ et Lua. Il vous permet de créer différents modes de jeu dans l'espace voxel. Prend en charge le multijoueur et de nombreux mods communautaires.
Le 10 novembre 2018, le numéro 7852 a été ouvert dans le suivi des bogues du projet - item_image_button []: bouton trop petit .
La description est la suivante:
Le bouton est trop petit, ce qui fait que l'image dépasse ses limites. Le bouton doit être de la même taille que les emplacements d'inventaire. Voir l'exemple ci-dessous (en utilisant une largeur et une hauteur de 1).Et une capture d'écran:
Dans la capture d'écran, vous pouvez voir une légère sortie d'images à l'extérieur de la bordure de la zone intérieure des boutons. Le bogue a été remarqué en 2018, et la raison n'a été trouvée que maintenant - en 2020.
Le prochain événement de cette merveilleuse histoire a été la publication de l'article technique « PVS-Studio: Analyse des demandes d'extraction dans Azure DevOps à l'aide d'agents auto-hébergés » en juillet 2020 de l'année. Pour donner un exemple d'intégration de l'analyseur dans Azure DevOps, le même jeu a été choisi - minetest. L'article contient plusieurs erreurs trouvées, mais nous nous intéressons à une en particulier:
V636L'expression 'rect.getHeight () / 16' a été implicitement convertie du type 'int' en type 'float'. Pensez à utiliser une conversion de type explicite pour éviter la perte d'une partie fractionnaire. Un exemple: double A = (double) (X) / Y;. hud.cpp 771
void drawItemStack(....)
{
float barheight = rect.getHeight() / 16;
float barpad_x = rect.getWidth() / 16;
float barpad_y = rect.getHeight() / 16;
core::rect<s32> progressrect(
rect.UpperLeftCorner.X + barpad_x,
rect.LowerRightCorner.Y - barpad_y - barheight,
rect.LowerRightCorner.X - barpad_x,
rect.LowerRightCorner.Y - barpad_y);
}
Lorsque vous divisez les valeurs de largeur et de hauteur par 16, la partie fractionnaire du résultat est ignorée, car division entière.
Et maintenant, six mois plus tard, les résultats de l'analyse ont été remarqués par les développeurs du jeu, et le problème 10726 - Correction des erreurs trouvées par un analyseur de code statique professionnel a été créé , où ils ont établi un lien entre ce bogue et le problème # 7852 . Ce bouton arrondi et déformé tailles.
conclusions
L'utilisation d'analyseurs de code statiques vous permet de gagner beaucoup de temps sur l'identification des erreurs dans votre code. On peut faire valoir que le bogue décrit est insignifiant, mais notre expérience montre qu'il s'agit d'un cycle de vie typique d'une erreur de toute criticité.
Disons qu'il y avait un bug sérieux ici. Ils auraient déployé tous leurs efforts pour le réparer, et dans une heure de débogage, ils l'auraient trouvé et réparé. Mais l'analyseur le trouverait toujours dans quelques minutes.
Ainsi, nous pouvons conclure que les méthodes automatiques de recherche d'erreurs apportent des avantages indéniables au projet développé. Des outils comme PVS-Studio doivent être considérés comme un ajout à la révision de code avec d'autres programmeurs, et non comme un remplacement pour ce processus.
Si vous souhaitez partager cet article avec un public anglophone, veuillez utiliser le lien de traduction: Svyatoslav Razmyslov. At-il fallu si longtemps pour trouver un bogue? ...