💈 🚋 🗾 Warum Sie sich für den PVS-Studio Static Analyzer entscheiden sollten, um ihn in Ihren Entwicklungsprozess zu integrieren ✋🏼 👖 🎌

PVS-Studio ist ein Tool zum Erkennen von Fehlern und potenziellen Schwachstellen im Quellcode von Programmen, die in C, C ++, C # oder Java geschrieben wurden, sowie ein SAST-Tool (Static Application Security Testing). Es soll als Teil der CI-Praxis verwendet werden und ermöglicht es dem Benutzer, Fehler in der frühesten Entwicklungsphase zu erkennen, bei der die Behebung fast nichts kostet.

Statische Code-Analyse

Während sich Softwareprojekte entwickeln, wachsen sie an Größe. Vergleichen Sie:

Linux-Kernel 1.0.0: 176.000 LOC
Linux-Kernel 5.0: 26.000.000 LOC
Photoshop 1.0: 128.000 LOC
Photoshop CS 6: 10.000.000 LOC

Wenn das Projekt wächst, wächst seine Komplexität schneller als linear. Dies erklärt, warum die Fehlerdichte mit der Codebasis wächst . Eine Möglichkeit, die wachsende Komplexität auszugleichen, besteht in der Verwendung statischer Code-Analysetools.

Ein statischer Analysator ist ein Software-Tool, das vorläufige Codeüberprüfungen durchführt und auf Codefragmente hinweist, bei denen mit hoher Wahrscheinlichkeit Fehler auftreten. Dies ermöglicht Entwicklern, die meisten Fehler in der frühesten Entwicklungsphase zu beheben, in der sie am billigsten zu beheben sind.

Die statische Analyse ersetzt andere Methoden zur Fehlererkennung nicht, sondern ergänzt sie, z. B. Codeüberprüfung, Komponententests, dynamische Analysen, Regressionstests, manuelle Tests usw.

Nehmen Sie zum Beispiel die Codeüberprüfung. Ein viel besseres Szenario besteht darin, einen Software-Analysator die für Sie trivialsten Fehler finden zu lassen, damit Sie sich auf nützlichere allgemeine Überprüfungen des Algorithmus konzentrieren können, anstatt Vergleichsfunktionen herauszufinden - zumal, wie unsere Erfahrung beweist, Das menschliche Auge ist schlecht darin, viele der Fehler zu bemerken, und es ist sehr wahrscheinlich, dass sie bei der Codeüberprüfung übersehen werden.

Ein weiterer Vorteil von statischen Analysewerkzeugen ist die umfangreiche Fehlermusterbasis. Sie können Fehler finden, die viele Programmierer möglicherweise gar nicht kennen, z. B. V698 , V718 , V1023 .

PVS-Studio

Wir empfehlen PVS-Studio, einen von unserem Team entwickelten statischen Code-Analysator. Es läuft auf 64-Bit-Windows-, Linux- und MacOS-Systemen und kann den Quellcode von Programmen für 32-Bit-, 64-Bit- und eingebettete ARM-Plattformen überprüfen.

Zum jetzigen Zeitpunkt unterstützt der Analyzer die folgenden Sprachen und Compiler:

Windows Visual Studio 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
Windows IAR Embedded Workbench, C / C ++ - Compiler für ARM C, C ++
Windows QNX Momentics, QCC C, C ++
Windows / Linux Keil µVision, DS-MDK, ARM Compiler 5/6 C, C ++
Windows / Linux Texas Instruments Code Composer Studio, Tools zur ARM-Codegenerierung C, C ++
Windows / Linux / MacOS. GNU Arm Embedded Toolchain, GCC-Compiler für Arm Embedded, C, C ++
Windows / Linux / MacOS. Clang C, C ++
Linux / macOS. GCC C, C ++
Windows MinGW C, C ++
Windows / Linux / MacOS. Java

Der Analysator wird mit einer ausführlichen Dokumentation in Englisch und Russisch geliefert. Die Beschreibungen der Diagnoseregeln enthalten Beispiele für richtigen und falschen Code. Sie enthalten auch Links zu Codeausschnitten aus echten Open-Source-Programmen.

Für die Spezialisten, die PVS-Studio als SAST-Tool verwenden , werden die Diagnosen den Standards Common Weakness Enumeration, SEI CERT Coding und MISRA zugeordnet. Hier sind die Zuordnungstabellen der PVS-Studio-Diagnose zu verschiedenen Standards:

Der Analyzer kann sowohl als eigenständiges Tool als auch als Plugin für Visual Studio und IntelliJ IDEA verwendet werden. Einige unserer Kunden haben in letzter Zeit auch PVS-Studio als Teil von SonarQube verwendet. Bei Verwendung als Plugin für SonarQube bietet der Analyzer zusätzliche Diagnosemeldungen.

Wir haben eine Reihe von Szenarien für die Verwendung von PVS-Studio mit CI-Systemen entwickelt. Da das Beobachten aller Szenarien außerhalb des Geltungsbereichs dieses Artikels liegt, lesen Sie bitte die Dokumentation. Hier sind nur ein paar Links, die Ihnen einen allgemeinen Eindruck vermitteln:

PVS-Studio erkennt effektiv eine Vielzahl von Fehlern, von Tippfehlern bis hin zu Speicherlecks . Dies ist dank der Datenflussanalyse, der symbolischen Ausführung, des Mustervergleichs und der Annotation von Methoden (einschließlich automatisierter Annotation) möglich. Weitere Informationen zu den Funktionsprinzipien des Analysators finden Sie im Artikel " Im PVS-Studio-Code-Analysator verwendete Technologien zum Auffinden von Fehlern und potenziellen Schwachstellen ".

Warum sollten Sie PVS-Studio verwenden?

Durch die Integration von PVS-Studio in Ihren Entwicklungsprozess werden viele der zu behebenden Fehler billiger. Dadurch sparen Sie Zeit, die Sie in die Implementierung einer neuen Funktion oder die Durchführung gründlicherer Tests auf hoher Ebene investieren können.

Bei regelmäßiger Verwendung hilft Ihnen der Analyzer, die Codequalität zu verbessern und die Wartung zu vereinfachen. Regelmäßige Fehlerbehebung und das Schreiben von qualitativ hochwertigem Code machen ihn weniger anfällig für Zero-Day-Schwachstellen. Dieses Thema wird im Artikel " Wie kann PVS-Studio beim Erkennen von Sicherheitslücken helfen? " Näher erläutert.

PVS-Studio ist am kostengünstigsten, wenn es von Teams mit fünf oder mehr Mitgliedern verwendet wird. Die ROI-Schätzung finden Sie im Artikel " PVS-Studio ROI ".

PVS-Studio in Projekte zu integrieren, die von ein paar Enthusiasten entwickelt wurden, wäre wahrscheinlich unpraktisch, aber auch kleine Projekte können davon profitieren - zumal wir kostenlose Lizenzoptionen für Studenten, Open Source-Entwickler usw. anbieten.

Unsere Neukunden erwerben in der Regel eine einjährige Lizenz. Nach Ablauf der Gültigkeitsdauer freuen sie sich bereits über die Funktionen und den Benutzer-Support-Service unseres Analysegeräts und verlängern die Lizenz um zwei oder drei Jahre, was viel billiger ist als die einjährige Lizenz. Hier können Sie die Preise erfragen und Ratschläge zur Lizenzierung einholen.

Werden Sie zu unseren Kunden und lassen Sie PVS-Studio Ihren Entwicklungsprozess reifer, das Beheben von Fehlern billiger und Ihren Code besser machen.

Wir unterstützen Sie schnell und kompetent. Ihre Fragen werden direkt von den Programmierern beantwortet, die die jeweiligen Module entwickeln. Dies garantiert auch in den kompliziertesten Situationen eine Antwort. Hier ist ein Beispiel: " False Positives in PVS-Studio: Wie tief das Kaninchenloch geht ."

Auf Kritik antworten

Programmierer stehen der Idee, statische Code-Analyse in ihren Entwicklungsprozess einzubeziehen, mitunter ablehnend gegenüber und kritisieren die statische Analysemethode im Allgemeinen oder PVS-Studio im Besonderen. Wenn Sie anfangen, tiefer zu graben, stellt sich heraus, dass ihre Kritik unbegründet ist und einfach das Ergebnis ihrer Zurückhaltung ist, irgendetwas im etablierten Entwicklungsprozess zu ändern. Mal sehen, welche typischen Argumente dafür sprechen, die Situation, auf die sie zurückgreifen, nicht zu ändern und was mit ihnen los ist.

"Die statische Analyse nimmt einen Teil Ihrer Arbeitszeit in Anspruch"

Aus dem Zusammenhang heraus ist die Aussage "die statische Analyse wird einen Teil Ihrer Arbeitszeit in Anspruch nehmen" wahr. Es braucht Zeit, um die vom Analysegerät ausgegebenen Warnungen regelmäßig auf neu geschriebenen oder geänderten Code zu überprüfen. Aber diese Idee muss fortgesetzt werden: "Aber sie wird viel weniger Zeit in Anspruch nehmen als andere Methoden zur Fehlererkennung."

Warum glauben die Leute, dass die Prüfung des Berichts eines statischen Analysators zeitaufwändig ist?

Diejenigen Programmierer, die noch nicht mit der Codeanalyse vertraut sind, verwechseln einmalige Testläufe und die regelmäßige Verwendung. Bei der ersten Ausführung gibt jedes Analysegerät eine große Liste von Warnungen mit einer hohen Rate an Fehlalarmen aus. Dies geschieht, weil das Tool noch nicht angepasst wurde. Mit den Einstellungen, die genau auf Ihre Bedürfnisse abgestimmt sind, werden Sie nicht viele Fehlalarme sehen, wenn Sie den Analysator regelmäßig ausführen. Mit anderen Worten, bei regelmäßiger Verwendung werden die meisten Diagnosen des Analysegeräts echte Fehler oder Geruchscodes erkennen. Sie müssen nur diese Anpassungen vornehmen.

Der Artikel " Umgang mit Einwänden: Statische Analyse nimmt einen Teil der Arbeitszeit in Anspruch " behandelt das Thema.

"Statische Analysegeräte erzeugen zu viel Rauschen (dh zu viele falsche Positive)"

Auch diese Aussage trifft zu, wenn Sie das Tool nicht richtig angepasst haben. Sobald Sie die Einstellungen von PVS-Studio nach Bedarf angepasst haben, können Sie damit rechnen, dass die False-Positives-Rate auf 10-20% sinkt. Das heißt, von fünf Warnungen verweisen vier auf echte Fehler oder Code, der in Zukunft sehr wahrscheinlich zur Fehlerquelle werden wird. Der Artikel " Eigenschaften des PVS-Studio Analyzers am Beispiel von EFL-Core-Bibliotheken, 10-15% von False Positives " zeigt ein Beispiel für die Anpassung des Analyzers.

Eine weitere Ursache für Missverständnisse ist die Versuchung, so viele Diagnosen wie möglich zu aktivieren, ohne deren genauen Zweck zu kennen. Wenn Sie beispielsweise den für eingebettete Systeme entwickelten MISRA-Regelsatz aktivieren, generiert der Analyzer beim Überprüfen einer klassischen Windows-Anwendung Hunderttausende von Warnungen, von denen keine für Sie von Nutzen ist. Eine irrelevante Diagnose ist besonders schädlich, wenn Sie erst mit dem Tool beginnen, da Sie möglicherweise einen falschen Eindruck von den Diagnosefunktionen des Tools bekommen. Der Artikel " Wie Sie die interessanten Warnungen des PVS-Studio-Analysators für C- und C ++ - Code schnell überprüfen können " hilft Ihnen dabei, Enttäuschungen zu vermeiden.

"Die Integration der statischen Analyse in den Entwicklungsprozess ist in Bezug auf Aufwand, Zeit und Geld zu kostspielig."

Dieses Anliegen wird durch den folgenden Kommentar anschaulich veranschaulicht:

Leider sind statische Analysegeräte selbst nichts anderes als Spielzeug. Es ist eine verdammt schwere Aufgabe, sie in Ihren Routinearbeitsprozess einzubeziehen, und einige Mitarbeiter müssen die Analyseergebnisse untersuchen und filtern. Jeder Versuch, diese Belastung auf normale Entwickler zu übertragen, ist normalerweise erfolglos.

Es ist nicht so schrecklich. Es gibt mindestens drei Vorgehensweisen, um statische Analysen reibungslos in große alte Projekte zu integrieren.

Übung 1. "Ratcheting", was Ivan Ponomarev in seinem Artikel " Statische Analyse in den Prozess einführen, nicht nur nach Fehlern suchen" gut erklärt.

Übung 2. Um unseren Benutzern einen schnellen Einstieg zu ermöglichen, empfehlen wir die Verwendung der " Unterdrückungsbasis ". Kurz gesagt, die Idee ist, dass Sie den Analysator ausführen und mehrere Warnungen erhalten. Da sich das Projekt seit vielen Jahren in der Entwicklung befindet und noch lebt, sich weiterentwickelt und profitabel ist, werden Sie wahrscheinlich nicht viele Warnungen erhalten, die auf kritische Mängel hinweisen. Mit anderen Worten, die meisten kritischen Fehler wurden bereits mit anderen - teureren - Mitteln oder als Reaktion auf das Feedback der Benutzer behoben. In diesem Fall können alle Fehler, die bei der ersten Überprüfung gefunden wurden, als technische Schulden angesehen werden, deren sofortige Behebung unvernünftig wäre.

Sie können PVS-Studio anweisen, diese Warnungen als irrelevant zu behandeln (wodurch die Auflösung der technischen Schulden auf einen späteren Zeitpunkt verschoben wird) und sie nicht erneut anzuzeigen. Der Analysator erstellt eine spezielle Datei, in der die Informationen zu derzeit irrelevanten Fehlern gespeichert werden, und gibt Warnungen nur für frisch geschriebenen oder geänderten Code aus. Der Mechanismus ist ziemlich schlau. Wenn Sie beispielsweise am Anfang einer CPP-Datei eine leere Zeile einfügen, erkennt der Analysator, dass diese Zeile keinen Unterschied macht, und schweigt. Die Unterdrückungsdatei kann versionsgesteuert sein. Es ist groß, aber es spielt keine Rolle, da Sie es nicht oft versionieren müssen.

Danach erhält jeder Programmierer in Ihrem Team nur die Warnungen, die durch frisch geschriebenen oder geänderten Code ausgelöst werden. Ab dem nächsten Tag können Sie den Analysator als Teil Ihrer Routinearbeit verwenden. Die technischen Probleme können Sie später beheben und die Einstellungen des Analysegeräts nach und nach anpassen.

Übung 3. Sie können die Aufgabe des Aufbaus und der Integration von PVS-Studio an unser Team delegieren, indem Sie einen Vertrag mit uns abschließen. Ein Beispiel für diese Vorgehensweise ist im Artikel " Wie das PVS-Studio-Team den Code der Unreal Engine verbesserte " beschrieben.

"Wir haben den Analysator gestartet, aber nichts Interessantes gefunden"

Dieses Szenario ist durchaus möglich, bedeutet jedoch nicht, dass der Analysator nicht von Nutzen sein wird. Das Problem ist, dass die Fehler bereits mit anderen, teureren Mitteln gefunden und behoben wurden. Es ist, als würde man einen Text, der bereits von einer Reihe von Korrektoren geprüft wurde, in Microsoft Word eingeben, um festzustellen, ob die integrierte Rechtschreibprüfung etwas gefunden hat. Es würde nur ein paar Fehler finden, wenn überhaupt, aber das bedeutet nicht, dass die Rechtschreibprüfung von Word beim Schreiben neuer Texte nutzlos ist.

Dieses Thema wird im Artikel " Philosophie der statischen Codeanalyse: Wir haben 100 Entwickler, der Analyzer hat nur wenige Fehler gefunden, ist der Analyzer unbrauchbar? " Ausführlicher besprochen.

"Ein statischer Analysator ist ein teures Werkzeug. Wir sollten einen zusätzlichen Programmierer / Tester engagieren »

Was dieses Argument wirklich sagt, ist, dass die Person nichts ändern will. Immerhin ist ihr Team schon seit einiger Zeit gewachsen und stellt neue Programmierer und Tester ein, aber das hat nicht dazu beigetragen, einen ausgereifteren Entwicklungsprozess zu erreichen. Trotzdem sollten wir dieses Argument noch näher erläutern.

Erstens ist die Einstellung einer anderen Person für die Fehlersuche viel teurer als der Kauf eines statischen Analysegeräts. Berechnen Sie einfach die jährliche Gehaltsabrechnung des neuen Mitarbeiters und addieren Sie die Steuern und Abgaben beim Einrichten eines neuen Arbeitsbereichs. In Anbetracht der sich daraus ergebenden Zahlen scheint das Argument, ein Software-Analysegerät sei zu teuer, überhaupt kein Argument zu sein. Außerdem nimmt ein statischer Analysator im Gegensatz zu Menschen keinen Urlaub, er erkrankt nicht und verlässt das Unternehmen nicht vollständig. Für ein großes Team von beispielsweise 100 Mitarbeitern müsste man nicht einen, sondern mehrere neue Mitarbeiter einstellen, um ein spürbares Ergebnis zu erzielen. In diesem Fall ist der Kauf eines statischen Analysators eine noch günstigere Lösung.

Zweitens wird das beste Ergebnis durch die Synergie zwischen verschiedenen in Kombination verwendeten Fehlererkennungstechniken erzielt. Einige Fehler lassen sich besser durch Komponententests diagnostizieren, andere durch manuelle Tests und so weiter. Stellen Sie sich vor, 10 Programmierer arbeiten an einem Projekt, mit vielen Unit-Tests, aber nicht einem einzigen Tester. Die Benutzer sind mit der Qualität des Projekts nicht zufrieden, daher sollten Sie einen Tester beauftragen, aber Sie tun dies nicht, weil "wir einen zusätzlichen Programmierer beauftragen sollten, damit es noch mehr Komponententests gibt!" kann man nicht eine weise Entscheidung nennen, oder? In diesem Szenario ist der QS-Prozess offensichtlich einbeinig und würde nur durch Hinzufügen manueller Tests verbessert. Gleiches gilt für die statische Analyse.

"Dynamische Analyse ist besser als statische Analyse"

Einige Fehler werden besser von statischen Analysegeräten diagnostiziert, andere von dynamischen Analysegeräten. Diese Arten von Tools ergänzen sich gegenseitig, sodass Sie nicht nur eines auswählen müssen.

Beispielsweise können dynamische Analysatoren nicht erreichbaren Code und viele der durch Tippfehler verursachten Fehler nicht erkennen. Einige der Arten von Fehlern, die bei der dynamischen Analyse nur schwer zu finden sind, werden im Artikel " Überprüfen des Codes des dynamischen Valgrind-Analysators mit einem statischen Analysator " beschrieben.

"Unit Testing ist besser als statische Analyse"

Wenn Sie zwischen dem Schreiben von Komponententests und der Verwendung von statischen Analysen wählen würden, wären die Tests wichtiger und wertvoller. Aber du musst nicht wählen; Sie sollten sowohl Unit-Tests als auch statische Analysen verwenden. Diese Techniken funktionieren sehr gut zusammen.

Hier sind die Argumente für die Verwendung der statischen Analyse zusammen mit Unit-Tests:

Tests selbst werden nicht getestet und enthalten häufig Fehler. In unseren Artikeln zeigen wir viele Beispiele von Fehlern, die in Unit-Tests in realen Projekten gefunden wurden. Statische Analysen können Fehler in Tests finden, die wiederum Fehler im Hauptcode finden können.
Es ist schwierig, den gesamten Code mit Tests abzudecken, insbesondere die Teile, die sich mit der Ausnahmebehandlung befassen. Im Gegensatz dazu überprüfen statische Analysatoren den gesamten Code.
Einige Bugs lassen sich nach Möglichkeit nur sehr schwer durch Unit-Tests erkennen. V597 (CWE-14) ist ein solches Beispiel.
Einige Fehler treten nur dann auf, wenn das Programm mit großen Datenmengen arbeitet. Daher ist es unpraktisch, solche Situationen in Komponententests zu simulieren. Ein solches Beispiel ist ein Überlauf einer 32-Bit-Variablen in einem 64-Bit-Programm ( V108 , V127 ).
Wenn ein Test nicht bestanden wird, kann der Fehler durch Ausführen des statischen Analysators einfacher und schneller gefunden werden als durch Debuggen. Natürlich würden Unit-Tests mehr Bugs finden, aber wenn Sie sie mit einer günstigeren Technik (dh statischen Analyse) finden können, warum nicht?
In verschiedenen Projekten finden wir Unmengen von Fehlern . Viele von ihnen sind stark mit Tests bedeckt, aber wie Sie sehen, helfen sie nicht viel. Es gibt also keinen Grund, warum Sie zusätzlich zu Unit-Tests keine statische Analyse anwenden sollten, um die Qualität und Zuverlässigkeit Ihres Codes zu verbessern.

"Zeitgenössische freie Compiler können die gleichen Fehler finden, die PVS-Studio kann"

Sicher, Compiler entwickeln sich weiter und erhalten neue Warnungen, die Fehler erkennen können. Im Vergleich zu professionellen proprietären Lösungen wie PVS-Studio kann man von Compilern jedoch nicht viel erwarten.

Gründe für PVS-Studio:

Effiziente Benutzerunterstützung
Hochentwickelte Infrastruktur (Integration mit anderen Produkten)
Leistungsstarke Diagnosefunktionen

Die ersten beiden Gründe sprechen bereits für PVS-Studio, aber auch für die Diagnose. Wir verbessern unser Produkt ständig, um anderen Anbietern einen Schritt voraus zu sein. Beispielsweise kann unser Tool einen interessanten Fehler erkennen, der im Artikel " 31. Februar " beschrieben ist.

Da wir uns darüber im Klaren sind, dass das oben Gesagte nicht ausreicht, um Skeptiker dazu zu bringen, ihre Meinung zu ändern, überprüfen wir die Compiler von Zeit zu Zeit, um zu zeigen, dass auch sie Fehler aufweisen, die PVS-Studio erkennen kann:

PS

Wenn Sie immer noch Zweifel haben, ob Sie PVS-Studio verwenden sollen, sehen Sie sich diese Liste der Fehler an, die es in verschiedenen Projekten gefunden hat .

Warum Sie sich für den PVS-Studio Static Analyzer entscheiden sollten, um ihn in Ihren Entwicklungsprozess zu integrieren