Müssen wir noch statische Analysen durchführen? [closed]

Mein Chef ist der Meinung, dass jeder Code, den wir schreiben (in C/C++), den Standards entsprechen muss, die von einem statischen Analysetool (wie MISRA/Lint) vorgegeben werden. Meine Meinung dazu ist, da Compiler heute gut entwickelt sind, ist dies wirklich erforderlich?

Die Frage hier ist, wie effektiv ist diese statische Analyse heutzutage?

Kurze Antwort: Ja.

Lange Antwort: Compiler werden in der Tat besser darin, bestimmte Arten von “Fehlern” zu analysieren, aber die “Tiefe”, mit der sie arbeiten, ist normalerweise viel geringer als die richtigen Werkzeuge dafür. Insbesondere Tools, die über Kompiliereinheiten hinweg funktionieren, wie Coverity, die (zum Beispiel) verstehen können, dass eine Funktion einen Zeiger als zurückgeben kann NULLund wenn dies der Fall ist, stürzt Ihr Code ab, da Sie nicht nachsehen NULL vor dem Zugriff auf den Zeiger.

Statische Analysetools können auch die Verwendung von Sperren überprüfen, was der Compiler normalerweise nicht kann.

Wie effektiv es wirklich ist, hängt davon ab, welches Tool Sie verwenden, welche Einstellungen und wie gut Sie den Code ansonsten testen. Also kommt auch “Code Coverage” ins Spiel. Gehen Sie beim Testen jeden Zweig Ihres Codes durch? Mit jedem möglichen Wert, der einen Unterschied im Verhalten bewirkt? Statische Analysetools können Fehler erkennen, die Ihre Tests möglicherweise nicht abdecken.

(Ob es in Ihrem speziellen Geschäft tatsächlich sinnvoll ist, ist natürlich eine ganz andere Diskussion – das müssen Ihr Chef und seine/ihre Chefs entscheiden.)

Es ist nicht so, dass Compiler nicht die Analyse durchführen können, die statische Analysewerkzeuge leisten. Das Problem ist, dass die statische Codeanalyse viel Zeit in Anspruch nimmt und normalerweise nicht für jede einzelne Kompilierung benötigt wird. Compiler sind im Allgemeinen für ein ausgewogenes Verhältnis von Codequalität und Kompilierungszeit optimiert. Wenn ein Compiler zufällig auf einen Fehler in Ihrem Code stößt, wird er Sie darüber informieren, aber er hat keine Zeit, aktiv nach Fehlern zu suchen.

Außerdem ist die statische Analyse wichtig, um Metriken zu generieren.

Diese Metriken können zeigen: zyklomatische Komplexität, die Tiefe Ihrer Klassenvererbung und viele andere / Abhängigkeitsdiagramm / % der Kommentare und vieles mehr (Verstehe hat zum Beispiel eine vollständige Liste der Funktionen ).

Ein guter Punkt ist auch, dass Sie mit den meisten statischen Analysetools spezifische Regeln hinzufügen können, die nützlich sein können, wenn Ihr Projekt / Unternehmen Codierungsregeln hat.

Sie können auch einen “Continuous Integration”-Server hinzufügen, der jeden Tag Ihren svn/git/other-Entwicklungszweig auscheckt und die Analyse nachts durchführt. Auf diese Weise können Sie am nächsten Tag den Code korrigieren, der nicht Ihrem Regelsatz entspricht.

Ja, es verleiht dem Code mehr Vertrauen.

MISRA-Regeln werden häufig in Echtzeitsystemen verwendet. Die Einhaltung von MISRA (durch Ausführen eines von Misra unterstützten Tools) wird von vielen Softwareprüfern verlangt.

Auch MISRA (oder ähnliche Standards) definieren einige umständliche Regeln, um Benutzer daran zu hindern, ausgefallene Dinge zu tun könnte schief gehen etwas Compiler. Zum Beispiel ist Zeigerarithmetik von MISRA verboten, aber kein Compiler wird Sie davor warnen.

BEARBEITEN:
Ein weiteres Beispiel: Der folgende Code tut, was viele Leute nicht erwarten (x != 1,1 wegen der Gleitkommagenauigkeit).

int main(int agrc, char** argv){

    float x = 1.1;
    if(x == 1.1)
        printf("Yes!\n");
    else
        printf("OMG!\n");
    return 0;
}

Dies wird von Compilern nicht erkannt (versucht auf gcc 4.6 und clang 3.2). Aber es wird von fast allen statischen Analysetools erkannt.

Gute statische Analysewerkzeuge analysieren Dinge wie zyklometrische Komplexität und sogar Dinge wie „Code Smells“ (siehe Martin Fowlers Refactoring-Buch). Sogar Zeilenzahlen in einer Datei oder in einer Funktion sind Hinweise darauf, dass Ihr Code verbessert werden kann. Ich glaube jedoch nicht, dass Lint diese Bereiche abdeckt.

Werden noch statische Analysetools benötigt? Unbedingt. Die von Compilern ausgegebenen Warnungen werden immer ausgefeilter, aber es gibt immer noch die Einschränkung, dass ein Compiler im Allgemeinen jeweils nur an einer Quelldatei arbeitet. Jede Datei wird kompiliert (*.c -> *.o), und die resultierenden Objektdateien werden am Ende miteinander verknüpft. Um eine wirklich effektive statische Analyse durchzuführen, müssen Sie die gesamte Codebasis auf einmal betrachten und einzelne Dateien sowie die Interaktionen zwischen ihnen analysieren. Compiler sind im Allgemeinen nicht so konzipiert, sodass einem Compiler allein normalerweise die Art von Dingen entgeht, die statische Analysatoren aufgreifen. Sie möchten diese Funktionalität nicht in den normalen Compiler einbauen, da dies eine ziemlich starke Auswirkung auf die Leistung hat. Eine statische Analyse, die in meinem aktuellen Projekt ausgeführt wird, dauert normalerweise viermal so lange wie eine normale Kompilierung. Sie möchten diesen zusätzlichen Overhead nicht bei jedem einzelnen Build, daher ist es am besten, ihn an ein separates, spezialisiertes Tool zu verlagern, das bei Bedarf ausgeführt werden kann (oder im Fall einiger moderner Compiler ein separater Satz von Befehlszeilenoptionen). die standardmäßig deaktiviert sind).

Wie effektiv ist die statische Analyse? Sehr. Mein Team findet eine große Anzahl potenzieller Probleme durch statische Analysetools, von denen die meisten mit anderen Methoden fast unmöglich zu finden wären. Es ist besonders gut geeignet, komplexe Probleme zu finden, die Menschen nicht gut erkennen können, wie z. B. solche, die die Wechselwirkung zwischen mehreren lokalen und globalen Variablen beinhalten. Selbst wenn Sie über eine hervorragende Testabdeckung verfügen, finden statische Analysatoren alle möglichen Dinge, die durch Tests allein schwer zu finden sind. Dies gilt umso mehr für die Embedded-Welt, wo das Testen tendenziell schwieriger und weniger automatisiert ist. Meiner Erfahrung nach haben uns statische Analysatoren sogar Probleme aufgezeigt, von denen wir nicht einmal wussten, dass wir sie überhaupt testen mussten.

Ich würde auf jeden Fall die Verwendung statischer Analysewerkzeuge für jedes nicht triviale Softwareprojekt empfehlen. Ich verwende tatsächlich zwei separate statische Analyseprogramme (einer ist in die Compiler-Suite integriert und der andere ist ein separates Dienstprogramm); Sie werden überrascht sein, was der eine fängt und der andere verfehlt. Ich empfehle dringend, dass Sie sich einen angepassten Satz von Regeln/Tests für Ihre Analyseläufe ausdenken, anstatt einfach einen Regelsatz wie MISRA zu übernehmen. Die Anforderungen jedes Projekts sind unterschiedlich, und viele branchenweite Spezifikationen wie MISRA enthalten viele Dinge, die für die meisten Menschen nicht erforderlich sind. Je mehr unnötige Dinge Sie überprüfen, desto länger dauert die Analyse, desto mehr Fehlalarme müssen Sie durchwühlen usw.