Dieser Artikel wurde maschinell übersetzt.

Innovation

Statische Codeanalyse und Codeverträge

Dino Esposito

Für viele lesen ist es schwer zu glauben, dass es jemals eine Zeit beim Drucken des gesamten Quellcode einer Anwendung könnte von oben nach unten und Bugs oder mögliche Fehlverhalten zu fangen. Die Komplexität moderner Software unpraktisch dieser Ansatz für den Menschen – aber nicht für einige Arten von smart-Software, wie z. B. statische Analyse-Tools.

Statische Analyse von Software besteht das Verhalten eines Codeabschnitts aus deren Anweisungen Herleiten. Ein Tool zur statischen Analyse führt der Prüfung von Quellcode durch schrittweise Aufbau einer Basis der Kenntnisse, die Anweisungen und deren Ausgabe richtig oder falsch nachweisen verwendet. Statische Analyse der Code nicht tatsächlich ausgeführt werden; nur Zeilen gelesen, und die Dinge herausfindet. Welche Art von Dinge?

Im Allgemeinen kann statische Analyse mögliche Fehler im Code zu identifizieren sowie anzugeben, wie genau bestimmter Codesegmente Erwartungen und Spezifikationen übereinstimmen.

Es hat seit einiger Zeit bekannt – zumindest soweit die großartige Arbeit getan von Alan Turing in den 30er Jahren –, dass es keine automatische und absolut zuverlässige Möglichkeit entscheiden, ob ein bestimmtes Programm ohne Fehler beendet wird. In jedem Fall Informatik basiert größtenteils auf Angleichung und gewarnt werden, haben Sie wahrscheinlich einen Fehler, um einige Zeilen ist eine wertvolle Hilfe. Skaliert diese Hilfe, um die Größe eines modernen Projekts und Sie können den wirklichen Wert sehen. Ein Tool zur statischen Analyse wahrscheinlich Anzahlen absolute Gewissheit, aber arbeiten in Echtzeit, wie Sie Ihre Klassen schreiben, er kann Ihnen Sofortige Rückmeldung über was in Ihrer Implementierung falsch sein können.

Statische Analysen und Tests

Es ist ein wesentlicher Unterschied zwischen Tests und statische Analyse. Als Entwickler aktiv schreiben den Test jedoch Passiv Ertragen die statische Analyse. Wenn Ihre Tests nicht tatsächlich wesentliche Bedingungen umfassen oder nicht mit erheblichen Werte überprüfen, wird nicht die Ergebnisse sinnvoll. Ein Tool für die statische Analyse gibt Ihnen Warnungen über Fakten (wie das Tool diese versteht), die einige der konfigurierten internen Regeln verletzen. Im Allgemeinen ist die erste fast keine Warnungen aus der statischen Analyse einen guten Überblick über die Qualität der Software. Auf der anderen Seite bedeutet immer Warnungen automatisch nicht Ihre Software ist fehlerhaft und wird beim ersten Ausführen fehl. Statische Analyse wird wahrscheinlich schwer Catch, Grenzfall Fehler erkennen, die das Potenzial Ihrer Anwendung zum Absturz. Wie bei testen, kann statische Analyse Mängel schon früh in der Entwicklungsphase und beschränkt somit die Auswirkungen der Software-Fehler zum gesamten Projekt abfangen.

Arten von statischen Analysatoren

Statische Analyse hat viele Facetten und eine Vielzahl von unterschiedlichen Ebenen der Implementierung. Eine sehr einfache statische Analyzer ist der Language-Compiler. Der Compiler den Quellcode durchläuft und vergleicht ihn mit der Syntaxregeln der Sprache. Dies ist der erste Schritt der Analyse. Moderne Compiler jedoch viel mehr tun.

Der neueste C# Compiler, erkennt z. B. Verstöße gegen das Liskovsche Prinzip, wenn in abgeleiteten Klassen Codeverträge summieren. Dieser Compiler kann häufig vorkommen, nicht verwendete Variablen hinweisen. Aber qualifizieren was Compiler erkennt und klassifiziert als Warnung nicht unbedingt als Fehler. Trotzdem ist der Compiler eine distinct-Schritt ausgeführt haben. Und es dauert eine Weile, je nach Projekt und die Umwelt.

Tools wie FxCop, oder besser noch, die Code-Analyse-KE Visual Studio 2010 führen Sie eine genauere Analyse des Codes und kann konfiguriert werden, bei Bedarf oder in jedem Build als ausführen Abbildung 1 zeigt.

Abbildung 1 für die Codeanalyse in einem Visual Studio-2010-Projekt

Darüber hinaus können Sie deklarativ festlegen die Regeln verwenden, wenn Ihr Code verarbeiten soll. Abbildung 2 zeigt ein Beispiel für die lange Liste der Warnungen, die möglicherweise angezeigt, wenn Sie die Option alle Regeln in der Visual Studio 2010 Codeanalyse aktivieren. Beachten Sie, dass einige dieser Warnungen sehr spezifischen und sehr nützlich für Code übersichtlicher und mehr anhaftenden an Microsoft vornehmen.NET Framework-Richtlinien.

(zum Vergrößern klicken)

Abbildung 2 Warnungen empfangen, wenn alle Regeln aktiviert sind

Informationen zur statischen Analyse der entscheidende Punkt ist, dass automatische Tools absolut ehrlich sind und ausschließlich basierte auf Verletzungen der Regeln Warnungen Ihnen. Erkannten Regelverstößen sind nicht unbedingt Fehler; aber wenn ein Verstoß gegen ein Bug ist, wahrscheinlich zeigt in Edge-Fällen und in voller Übereinstimmung mit Murphys Gesetz – nur wenn es den meisten Schaden tun.

Neben on-Demand-Tools wie Compilern und FxCop-ähnliche Einrichtungen, kann eine andere Kategorie von Tools für Sie viel Feedback bereitstellen – aber sie asynchron arbeiten. Zu dieser Kategorie gehört ReSharper, die die gleiche Art von praktische Vorschläge Codeanalyse, sondern dynamisch als Eingabe bereitstellt. Es bietet auch den Code für Sie zu Lasten der klicken auf eine oder zwei zu bearbeiten. ReSharper erkennt beispielsweise nicht zugewiesene Variablen, Unerreichbarer Code, mögliche null-Verweise und eine Vielzahl von Codegerüche wie virtuelle Aufrufe in einem Konstruktor und den Zugriff auf geänderte Verschlüsse in LINQ-Ausdrücke. Noch wichtiger ist, kann ReSharper Sie Ihre eigenen Codegerüche zu formalisieren und automatisch suchen und Ersetzen auf intelligente Weise während der Eingabe. Weitere Informationen und ein ausführliches Beispiel Schritt für Schritt das ReSharper strukturelle suchen und ersetzen den Blogbeitrag unter bit.ly/eCMvCL.

Schließlich, statische Analyse in der.NET Framework 4 und Visual Studio 2010 auch erfolgt mithilfe des statischen Checker-Tools vom Codeverträge Team erstellt.

Statische Prüfung in Aktion

Zusammen mit Code-Verträge stellt Microsoft das statische Checker-Tool, das kann Code durchlaufen, auch ohne Sie kompilieren und Hervorheben von Code-Verträge werden nicht überprüft oder nur rechts nachweisen unmöglich oder falsch. Nur, wenn Sie Visual Studio 2010 Premium oder Ultimate oder Visual Studio Team System 2008 haben, können Sie die statische Prüfung erhalten. Diese Versionsanforderungen in Einklang mit den Anforderungen für die Code-Analyse-KE sind – d. h., keine dieser Funktionen sind in Visual Studio Professional oder Express-Editionen verfügbar.

Wie die Intermediate Language-Laufwerke ist der statische Checker separater Download, der Visual Studio 2010 verbessert. Sie erhalten die neuesten Codeverträge Bits aus bit.ly/fF3wzl. Sie müssen explizit statische Prüfung auf Basis-Konfiguration pro-Projekt aktivieren, wie in gezeigt Abbildung 3.

Abbildung 3 Visual Studio 2010 Verträge statische Prüfung des Codes zu aktivieren

Die statische Prüfung können Sie ggf. im Hintergrund ausgeführt und können explizit Wellenlinien für jede Warnung anzeigen. Ausführung im Hintergrund bedeutet, dass die statische Prüfung geplant wird, parallel mit dem Compiler ausgeführt wird, wie ein Build erstellt wird und der Code geändert wird.

Sie können die statische Prüfung implizite als auch explizite Verträge gesucht haben. Ein expliziter Vertrag ist ein Vertrag, die Sie in der Methode einer Klasse, wie z. B. Vorbedingung einer Nachbedingung oder eine invariante deklarieren. Darüber hinaus kann die statische Prüfung auch einige integrierte Codeverträge berücksichtigen und überprüfen, ob Arrayindizes bleiben immer innerhalb der Arraygrenzen, ob null-Verweise verwendet werden oder wenn eine Division durch Null auftritt. Sie steuern die implizite Codeverträge über die Kontrollkästchen angezeigt, Abbildung 3. Beachten Sie, dass die implizite Codeverträge Aktivieren Ihrer Ausgabefenster mit einer Tonne von Meldungen und Warnungen überschwemmen kann. Sie möchten möglicherweise nicht dazu die Zeit und wahrscheinlich nicht nach dem Beginn. Hier ist ein Beispiel für Code, der als potenzielle Fehler abgefangen, wenn Sie den implizite Verpflichtungen der Array-Grenzen-Vertrag haben, auf:

var numbers = new int[2];
numbers[3] = 0;

Großteil der Leistung von statischen Checker ergibt sich jedoch aus mit expliziten Verträge, wie z. B. Vorbedingungen und Postconditions.

Explizite Verträge

Genommen Sie an, Sie haben den folgenden Code in Ihre Methoden:

var orderId = GetLatestOrderId(); 
ProcessOrder(orderId);

Eine Variable aus einem Funktionsaufruf abgerufen und dann an eine andere Methode zur weiteren Verarbeitung übergeben. Es ist nicht viel alle statischen Checker um zu versuchen, diese Anweisungen richtig oder falsch ohne einige explizite Vertragsinformationen Beweisen tun können. Andererseits, wenn die GetLatestOrderId-Methode eine sinnvolle Nachbedingung, wie im folgenden Code macht die Checker möglicherweise zu prüfen, ob der nachfolgende Aufruf gültig ist:

public int GetLatestOrderId()
{
  Contract.Ensures(Contract.Result<int>() >0);
  ...
return n;
}

GetLatestOrderId-Methode deklariert explizit, dass es einen Wert größer als 0 (null) zurückgegeben wird. Die Prüfung des Durchlaufs macht, packt diese Information und seiner Knowledgebase hinzugefügt. Später wenn er feststellt, dass der Rückgabewert von GetLatestOrderId-Methode als Eingabe für eine andere Methode mit einem expliziten Voraussetzung verwendet wird, kann die Checker vernünftigerweise versuchen, ob der Vorgang mit deklarierten Verträge konsistent ist. Betrachten Sie den folgende Voraussetzung Vertrag:

public void ProcessOrder(int orderId)
{
  Contract.Requires<ArgumentException>(orderId >0);
  ...
}

Diese zwei explizite Verträge bieten genügend Informationen zu Checker Vertrag nachzuweisen. In diesem Fall wird nicht Sie jede zusätzliche Warnung erhalten. Aber was, wenn einige dieser Verträge fehlen? Die statische Prüfung gibt eine Ausgabe ähnlich, was Sie in sehen Abbildung 4. Der Designdetektiv erkennt, sagen wir, eine Methode hat einen Vertrag erfordert und empfängt Daten von einem anderen, die etwas über die zurückgegebene Ausgabe nicht sagen.

Abbildung 4 bisher nicht praxiserprobtes Verträge

Es sollte klar sein, jetzt, um die statische Prüfung optimal, Codeverträge alle im gesamten Code verwenden müssen. Expliziter Verträge bringen Sie in, desto zuverlässiger kann die statische Prüfung.

Übernehmen und Assert

Manchmal, jedoch haben Sie neuen Code mit legacy-Code integrieren, die andere geschrieben haben und kann nicht aktualisiert werden. Haben der legacy-Code alle Verträge, wirst du Warnungen aus dem statischen ärgerlich erhalten. Der Code-Verträge-API bietet eine Problemumgehung.

Im wesentlichen, bisher nicht praxiserprobtes Vertrag Warnungen stammen aus Mangel an Informationen – die Checker ist nicht die erforderliche Informationen gefunden. Jedoch als Entwickler können Sie weitere Details bereitstellen – insbesondere Annahmen. Schauen Sie sich Abbildung 5.

Abbildung 5 eine Warnung aus dem statischen

Sie sehen eine QuickInfo, die über eine mögliche Verweis warnt. Offenbar, die Variable Kontext ohne zugewiesen wurde verwendet wird. Wer ist verantwortlich für die QuickInfo? Ist es das Überprüfungsprogramm oder ist etwas anderes?

In diesem Fall kommt die QuickInfo von ReSharper, deren Analyse-Engine möglichen null-Verweis korrekt bestimmt. Warum? nicht wir eine ähnliche Nachricht aus dem Das ist aufgrund der ersten Zeile in Abbildung 5:

Contract.Assume(context != null);

Mit dieser Anweisung, die Sie zu der Checker garantieren, dass die Variable Kontext ist nie null. Der Designdetektiv nur Sie Vertrauensstellungen und fügt diese Einzelinformation zu seiner Knowledgebase. ReSharper zur nicht vollständigen Unterstützung für die derzeit Verfügung.NET Code-Verträge, die erklärt, warum es immer noch eine Warnung gibt. Auf der anderen Seite unterstützt ReSharper einen eigenen Satz von Anmerkungen, die Sie in der gleichen Weise wie mit Annahmen verwenden können. Finden Sie unter bit.ly/lVSnkj für weitere Details.

Optimale Nutzung der statischen Analyse

Statische Analyse ist schwierig, und es ist wahrscheinlich nicht einmal eine exakte Wissenschaft. Es kommt oft vor, dass Sie Ihren Code mit Vertragsinformationen mit den besten Absichten, nur um herauszufinden, dass sie den Build-Prozess erheblich verlangsamt füllen. Es gibt ein paar Ansätze zum Optimieren der Verwendung von Verträgen und nachfolgende Analyse berücksichtigt.

Zuerst, Sie möchten eine besonderes Build-Konfiguration erstellen und auf, die nur statische Überprüfung aktivieren. Sie wechseln, da in regelmäßigen Abständen, greifen das Feedback und anwenden. Wenn Sie fertig sind, wechseln Sie zum Aufbau Ihrer Lösung ohne die zusätzliche Belastung der statischen Analyse wie gewohnt.

Zweitens können Sie versuchen, verwenden Verträge stückweise. Sie Verträge umfassend im Code anwenden, aber Sie Verträge auf Assemblyebene deaktivieren. Hierzu können Sie die Eigenschaften der Assembly einfach das folgende Attribut hinzufügen:

[assembly: ContractVerification(false)]

Als Nächstes die Vertrag überprüft nur, in dem Sie derzeit Schwerpunkt sind wieder aktivieren: Klasse, Methode oder Assembly. Sie verwenden das gleiche Attribut mit dem Wert True.

Zusammenfassung

Statische Analyse ist eine Technik, die die Richtigkeit des Quellcodes zu bewerten, ohne es ausgeführt werden soll. Es gibt einige Tools, die dazu, verschiedene Blöcke. Eine ist einfach der Compiler; ein weiteres Tool Codeanalyse ist die statische Prüfung – eine ausführbare Datei, die in der Regel mit den Build-Prozess integriert. In der.NET Framework funktioniert ein spezielles Tool für die statische Prüfung Fakten über Code vom Codeverträge zu lernen. Der Prüfer wertet diese Fakten und unterstreicht mögliche Fehler und Verletzungen der Vertrag.

Zu einem Zeitpunkt, wenn fortlaufend erhöht die Komplexität und Entwicklungsteams immer ausgeführt wird, über ausreichend Zeit integrierte statische Analyse speichert ein wenig Zeit in Builds und mehr wichtiger ist, erspart Ihnen böse Bugs, die Ihre Software nur in Ausnahmefällen getroffen.

Dino Esposito st der Autor von "Programming Microsoft ASP.NET MVC"(Microsoft Press, 2010) und Mitverfasser von"Microsoft.NET: Entwerfen von Anwendungen für Unternehmen "(Microsoft Press, 2008). Esposito lebt in Italien und ist ein weltweit gefragter Referent bei Branchenveranstaltungen. Führen Sie ihn auf Twitter bei twitter.com/despos.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Manuel Fahndrich