Sicherlich haben Sie sich gefragt, wessen Code besser ist: ein Open-Source-Projekt oder ein geschlossenes? Nach dem Lesen unseres Blogs könnten Sie denken, dass alle Fehler von Open Source-Projekten gesammelt wurden. Das ist aber nicht so. In allen Projekten sind Fehler vorhanden, unabhängig davon, wie sie gespeichert sind. Und die Qualität wird dort besser, wo sie verbessert wird. Dies ist eine kleine Anmerkung darüber, wie ein Fehler in einem Projekt 2 Jahre lang behoben wurde, aber in 5 Minuten hätte behoben werden können.
Chronologie der Ereignisse
Minetest ist eine plattformübergreifende Open-Source-Spiel-Engine, die etwa 200.000 Zeilen C-, C ++ - und Lua-Code enthält. Sie können verschiedene Spielmodi im Voxelraum erstellen. Unterstützt Multiplayer und viele Community-Mods.
Am 10. November 2018 wurde die Ausgabe Nr. 7852 im Bug-Tracker des Projekts geöffnet - item_image_button []: Schaltfläche zu klein .
Die Beschreibung lautet wie folgt:
Die Schaltfläche ist zu klein, sodass das Bild seine Ränder überschreitet. Die Schaltfläche sollte dieselbe Größe wie die Inventarplätze haben. Siehe Beispiel unten (mit Breite und Höhe von 1).Und ein Screenshot:
Im Screenshot sehen Sie einen leichten Bildausfluss außerhalb des Randes des inneren Bereichs der Schaltflächen. Der Fehler wurde bereits 2018 bemerkt und der Grund wurde erst jetzt gefunden - im Jahr 2020.
Das nächste Ereignis in dieser wunderbaren Geschichte war die Veröffentlichung des technischen Artikels " PVS-Studio: Analyse von Pull-Anforderungen in Azure DevOps mit selbst gehosteten Agenten " im Juli 2020 des Jahres. Um ein Beispiel für die Integration des Analysators in Azure DevOps zu geben, wurde dasselbe Spiel ausgewählt - Minetest. Der Artikel enthält mehrere gefundene Fehler, aber wir sind an einem bestimmten interessiert:
V636Der Ausdruck 'rect.getHeight () / 16' wurde implizit vom Typ 'int' in den Typ 'float' umgewandelt. Erwägen Sie die Verwendung eines expliziten Typgusses, um den Verlust eines Bruchteils zu vermeiden. Ein Beispiel: 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);
}
Wenn Sie die Werte für Breite und Höhe durch 16 teilen, wird der Bruchteil des Ergebnisses verworfen, weil Division ist eine ganze Zahl.
Und jetzt, sechs Monate später, wurden die Ergebnisse der Analyse von den Spieleentwicklern bemerkt, und Problem 10726 - Fehler behoben , die von einem professionellen statischen Code-Analysator gefunden wurden , wo sie eine Verbindung zwischen diesem Fehler und Problem # 7852 herstellten . Diese abgerundeten und verzerrten Tastengrößen.
Schlussfolgerungen
Durch die Verwendung von statischen Codeanalysatoren können Sie viel Zeit beim Erkennen von Fehlern in Ihrem Code sparen. Es kann argumentiert werden, dass der beschriebene Fehler unbedeutend ist, aber unsere Erfahrung zeigt, dass dies ein typischer Lebenszyklus eines Fehlers jeglicher Kritikalität ist.
Nehmen wir an, hier gab es einen schwerwiegenden Fehler. Sie hätten alle Anstrengungen unternommen, um das Problem zu beheben, und in einer Stunde des Debuggens hätten sie es gefunden und behoben. Aber der Analysator würde es in ein paar Minuten immer noch finden.
Wir können daher den Schluss ziehen, dass automatische Methoden zum Auffinden von Fehlern dem zu entwickelnden Projekt unbestreitbare Vorteile bringen. Tools wie PVS-Studio sollten als Ergänzung zur Codereview mit anderen Programmierern angesehen werden und nicht als Ersatz für diesen Prozess.
Wenn Sie diesen Artikel einem englischsprachigen Publikum zugänglich machen möchten, verwenden Sie bitte den Übersetzungslink: Svyatoslav Razmyslov. Musste es so lange dauern, einen Fehler zu finden? ...