Allmählich und unauffällig entwickelt sich eine Situation, in der die Komplexität seriöser C ++ - Projekte unerschwinglich wird. Leider kann sich ein C ++ - Programmierer jetzt nicht mehr nur auf seine eigenen Stärken verlassen.
Erstens gibt es so viel Code, dass es nicht mehr möglich ist, wenn sich mindestens ein paar Programmierer im Projekt befinden, die das gesamte Projekt kennen. Zum Beispiel enthielt der Linux-Kernel 1.0.0 ungefähr 176.000 Codezeilen. Das ist viel, aber es war möglich, eine Kaffeemaschine in die Nähe zu stellen und in ein paar Wochen mehr oder weniger den gesamten Code zu betrachten und die allgemeinen Prinzipien seiner Funktionsweise zu verstehen. Wenn wir den Linux 5.0.0-Kernel verwenden, beträgt die Größe der Codebasis bereits etwa 26 Millionen Codezeilen. Der Kernel-Code ist fast 150-mal gewachsen. Sie können nur mehrere Teile des Projekts auswählen und an deren Entwicklung teilnehmen. Es ist unmöglich, sich hinzusetzen und herauszufinden, wie genau dies alles funktioniert und welche Beziehungen zwischen den verschiedenen Abschnitten des Codes bestehen.
Zweitens entwickelt sich die C ++ - Sprache weiterhin rasant weiter. Einerseits ist dies gut, da es Konstruktionen gibt, mit denen Sie kompakteren und sichereren Code schreiben können. Andererseits werden alte Großprojekte aufgrund der Abwärtskompatibilität heterogen. Sie verweben alte und neue Ansätze zum Schreiben von Code. Die Analogie mit Ringen an einem Baumabschnitt bittet. Aus diesem Grund wird es von Jahr zu Jahr schwieriger, sich in in C ++ geschriebene Projekte zu vertiefen. Es ist notwendig, den Code gleichzeitig zu verstehen, sowohl im C-Stil mit Klassen als auch in modernen Ansätzen (Lambdas, Bewegungssemantik usw.). Das vollständige Erlernen von C ++ dauert zu lange. Da es jedoch weiterhin erforderlich ist, Projekte zu entwickeln, beginnen die Benutzer mit dem Schreiben von Code in C ++, ohne alle Nuancen bis zum Ende untersucht zu haben. Dies führt zu zusätzlichen Fehlern, aber es ist irrational, anzuhalten und zu warten, bis sich alle Entwickler mit C ++ vertraut gemacht haben.
Ist die Situation hoffnungslos? Nein. Eine neue Klasse von Werkzeugen hilft: statische Code-Analysatoren. Viele erfahrene Programmierer kräuselten in diesem Moment ihre Lippen, als hätten sie eine Zitrone gerutscht :). Wir kennen diese Linter ... Es gibt viele Botschaften, ein bisschen Sinn ... Ja, und was ist diese neue Klasse von Werkzeugen ?! Wir linter starteten vor 20 Jahren.
Trotzdem wage ich zu behaupten, dass dies genau eine neue Klasse von Werkzeugen ist. Was vor 10 bis 20 Jahren geschah, sind überhaupt nicht die Werkzeuge, die heute als statische Analysegeräte bezeichnet werden. Erstens spreche ich nicht über Tools zur Codeformatierung. Sie beziehen sich auch auf statische Analysewerkzeuge, aber jetzt geht es darum, Fehler im Code zu identifizieren. Zweitens verwenden moderne Tools ausgefeilte Analysetechnologien, die die Verbindungen zwischen verschiedenen Funktionen berücksichtigen und bestimmte Codeabschnitte tatsächlich virtuell ausführen. Dies sind nicht die gleichen 20 Jahre alten Linters, die auf regulären Ausdrücken basieren. Ein normaler statischer Analysator kann übrigens überhaupt
nicht mit regulären Ausdrücken durchgeführt werden. Um Fehler zu finden, werden Technologien wie Datenflussanalyse, automatische Methodenanmerkung, symbolische Ausführung usw. verwendet.
Dies sind keine abstrakten Wörter, sondern die Realität, die ich als einer der Schöpfer des PVS-Studio-Tools beobachte. In diesem
Artikel erfahren Sie, warum Analysatoren interessante Fehler finden können.
Es ist jedoch viel wichtiger, dass moderne statische Analysegeräte über umfassende Kenntnisse der Fehlermuster verfügen. Darüber hinaus wissen Analysatoren mehr als selbst professionelle Entwickler. Es wurde zu schwierig, beim Schreiben von Code alle Nuancen zu berücksichtigen und sich daran zu erinnern. Wenn Sie beispielsweise nicht irgendwo speziell darüber lesen, werden Sie nie vermuten, dass Aufrufe der
Memset- Funktion zum Löschen privater Daten manchmal verschwinden, da der Aufruf der
Memset- Funktion aus Sicht des Compilers redundant ist. Inzwischen ist dies eine schwerwiegende Sicherheitslücke
CWE-14 , die buchstäblich
überall zu finden
ist . Oder wer weiß zum Beispiel, was bei einer solchen Behälterfüllung gefährlich ist?
std::vector<std::unique_ptr<MyType>> v; v.emplace_back(new MyType(123));
Ich denke, dass nicht jeder sofort erkennen wird, dass ein solcher Code potenziell
gefährlich ist und zu Speicherlecks führen kann.
Statische Analysegeräte sind nicht nur umfassend mit Mustern vertraut, sondern auch unendlich aufmerksam und werden nie müde. Im Gegensatz zu einer Person sind sie beispielsweise nicht zu faul, um die Header-Dateien zu betrachten, um sicherzustellen, dass
isspace und
sprintf echte Funktionen sind und keine
verrückten Makros , die alles verderben. Solche Fälle zeigen die Essenz der Schwierigkeit, Fehler in großen Projekten zu finden: Etwas ändert sich an einem Ort, bricht aber an einem anderen.
Ich bin überzeugt, dass die statische Analyse bald ein wesentlicher Bestandteil von DevOps sein wird - sie wird so natürlich und notwendig sein wie die Verwendung eines Versionskontrollsystems. Dies geschieht bereits schrittweise auf Konferenzen, die sich dem Entwicklungsprozess widmen und bei denen die statische Analyse zunehmend als eine der ersten Verteidigungslinien zur Bekämpfung von Fehlern erwähnt wird.
Die statische Analyse dient als eine Art Grobfilter. Es ist ineffizient, mit Unit-Tests oder manuellen Tests nach dummen Fehlern und Tippfehlern zu suchen. Es ist viel schneller und billiger, sie sofort nach dem Schreiben des Codes zu beheben und statische Analysen zu verwenden, um Probleme zu erkennen. Diese Idee sowie die Bedeutung der regelmäßigen Verwendung des Analysators werden im Artikel „
Statische Analyse in den Prozess einbetten und keine Fehler damit suchen “ ausführlich beschrieben.
Jemand könnte sagen, dass es keinen Sinn macht, spezielle Tools zu verwenden, da der Compiler auch lernt, solche statischen Überprüfungen durchzuführen. Ja das stimmt. Statische Analysatoren stehen jedoch natürlich nicht still und wie spezialisierte Tools Compiler übertreffen. Beispielsweise finden wir dort jedes Mal, wenn wir LLVM überprüfen,
Fehler mit PVS-Studio.
Die Welt bietet eine Vielzahl von Tools für die statische Code-Analyse. Wie sie sagen,
wählen Sie nach Ihrem Geschmack. Möchten Sie bereits beim Schreiben von Code viele Fehler und potenzielle Schwachstellen finden? Verwenden Sie statische Code-Analysatoren und verbessern Sie die Qualität Ihrer Codebasis!
Wenn Sie diesen Artikel einem englischsprachigen Publikum zugänglich machen möchten, verwenden Sie bitte diesen Link: Andrey Karpov.
Warum statische Analyse eine komplexe C ++ - Codebasis verbessern kann