(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren

Qualitätssicherung für verwalteten Sourcecode

Veröffentlicht: 05. Mrz 2007
Von John D'Addamio

In diesem Dokument werden Standardverfahren für die Qualitätssicherung für verwalteten Sourcecode beschrieben. Einige dieser Methoden gelten für die Revision von verwaltetem und nicht verwaltetem Code. Andere sind speziell auf die Durchsicht von verwaltetem Code anwendbar. In diesem Artikel wird davon ausgegangen wird, dass Sie sich mit mindestens einer verwalteten Sprache auskennen. Es wird jedoch nicht vorausgesetzt, dass Sie Erfahrung in der Qualitätssicherung für verwalteten Sourcecode haben.

Auf dieser Seite

 Einführung
 Empfohlene verwandte Richtlinien
 Empfohlene Methoden
 Schlussbemerkung

Einführung

Die Qualitätssicherung für verwalteten Sourcecode unterscheidet sich von der Überprüfung von nicht verwaltetem Code. In mancher Hinsicht ist die Prüfung von verwaltetem Code einfacher als die von sonstigem Code. Der Compiler überprüft Typen, um eine versehentliche Zuweisung von inkompatiblen Daten zu einem Objekt zu verhindern. Der Compiler überprüft auch die Verwendung von Variablen, die nicht initialisiert wurden. Diese und andere Kompilierungsüberprüfungen verhindern eine Reihe von Fehlern, nach denen bei Codeüberprüfungen gesucht werden musste. Darüber hinaus werden durch Überprüfungen zur Laufzeit andere allgemeine Probleme erkannt, und der mögliche Schaden wird durch Auslösen einer Ausnahme eingegrenzt. Demgegenüber gibt es bei verwaltetem Code jedoch auch bestimmte Probleme, die in anderen Sprachen nicht vorhanden sind, wie beispielsweise im Hinblick auf Ressourcendateien und XML-Elemente in der Quelldatei selbst.

In diesem Dokument werden Standardverfahren für die Qualitätssicherung für verwalteten Sourcecode beschrieben. Es wird davon ausgegangen, dass Sie sich mit mindestens einer verwalteten Sprache auskennen, wie beispielsweise C# oder VB.NET. Es wird jedoch nicht vorausgesetzt, dass Sie Erfahrung in der Qualitätssicherung für verwalteten Sourcecode haben.

Empfohlene verwandte Richtlinien

Es gibt viele themenverwandte Richtlinien auf MSDN. Obwohl viele dieser Richtlinien als Designrichtlinien gedacht sind, gelten sie auch für Qualitätsprüfungen. Dazu gehören:

  1. .NET-Designrichtlinien

  2. Namensrichtlinien

  3. Richtlinien für Umwandlungstypen

Empfohlene Methoden

Verwenden von FxCop zur Durchsetzung Ihrer Codierungsstandards

FxCop ist ein Codeanalysetool, das .NET-verwaltete Codeassemblys auf Übereinstimmung mit den .NET-Designrichtlinien überprüft, auf die zuvor verwiesen wurde. FxCop bietet standardmäßige Codeanalyseregeln und ermöglicht Ihnen die Anpassung der Regeln für Ihr Projekt. Eine Unterdrückung von FxCop-Warnungen ist im Quellcode ebenso erlaubt. Weitere Informationen sowie FXCop und die dazugehörige Dokumentation können kostenlos von der FxCop-Teamseite heruntergeladen werden.

Führen Sie FxCop über den zu überprüfenden Code aus

Definieren Sie eine Standardbuildkonfiguration, die eine FxCop-Codeanalyse ausführt, die jedes Projekt implementieren muss. Stellen Sie als Bestandteil einer Codeüberprüfung sicher, dass das Projekt Ihre Standard-FxCop-Buildkonfiguration korrekt implementiert hat, und dass der überprüfte Code die FXCop-Bewertung besteht, indem die FxCop-Konfiguration erstellt wird.

Überprüfen der Unterdrückung von FxCop-Fehlern im Quellcode

Durchsuchen Sie den Code, der überprüft wird, auf eine Unterdrückung von FxCop-Nachrichten. Verwenden Sie Strg+F, um das aktuelle Projekt nach „CodeAnalysis“ zu durchsuchen. Wenn Sie FxCop-Unterdrückungen finden, überprüfen Sie, dass diese wirklich notwendig sind, und dass der Grund für die Unterdrückung in den Kommentaren klar begründet wird. In manchen Fällen stellen Sie möglicherweise fest, dass die Unterdrückung nicht notwendig ist, die Person, die den Code geschrieben hat, jedoch nicht wusste, wie dieser Fehler korrigiert werden kann. Die folgende Unterdrückung ist beispielsweise nicht nötig.

// FxCop doesn't like the "\n\n" so we're suppressing the error message 
here.
[System.Diagnostics.CodeAnalysis.SuppressMessage
("Microsoft.Globalization", "CA1303:DoNotPassLiteralsAsLocalizedParameters", MessageId = 
"System.Windows.Forms.TextBoxBase.AppendText(System.String)")]
this.resultsTextBox.AppendText ("\n\n" + Strings.contextErrorMessage);

Durch einfache Änderung des Codes, wie hier gezeigt, wird der FxCop-Fehler verhindert.

this.resultsTextBox.AppendText( Environment.NewLine + 
Environment.NewLine + Strings.contextErrorMessage);

Überprüfen der Logik

Die wichtigsten Elemente bei einer Überprüfung von Code sind die Suche nach Fehlern in der Logik und die Durchsetzung der Codierungsstandards des Teams. Durch die Verwendung von FxCop zur Durchsetzung Ihrer Codierungsstandards können Sie mehr Zeit für die Überprüfung der Logik des Codes aufwenden.

.NET Framework verfügt über viele Klassen, und jede Klasse verfügt über zahlreiche Methoden. Niemand erwartet, dass Sie alle Klassen oder Methoden kennen. Bedienen Sie sich der IntelliSense-Beschreibungen für die Klassen oder Methoden.

Wenn die Funktion des Codes durch die vorhandenen Kommentare und die IntelliSense-Beschreibungen der Klassen oder Methoden nicht klar ist, sind nicht genügend Kommentare für den Code vorhanden. Wenn Sie der Meinung sind, dass die Logik nicht wie vom Autor beschrieben funktioniert, ist die Logik entweder fehlerhaft oder der Code verfügt nicht über ausreichende Kommentare zur Erklärung der Funktion.

Erstellen des Codes

Es ist sinnvoll, den Code in allen Konfigurationen des Projekts zu erstellen. Der Autor hat möglicherweise vergessen, ihn für alle Konfigurationen zu erstellen. Wenn der Code nicht für alle Konfigurationen vorhanden ist, sollten Sie den Autor bitten, die Fehler zu korrigieren, bevor der Code übermittelt wird.

Es ist beispielsweise üblich, die Releasekonfiguration so zu definieren, dass Komponententests ausgeschlossen werden. Wenn Änderungen an der Signatur einer Methode vorgenommen werden, die Komponententests jedoch nicht aktualisiert werden, würde der Code in der Releasekonfiguration korrekt erstellt werden, nicht jedoch in der Debugkonfiguration.

Suchen der Komponententests

Erwarten Sie beim Überprüfen von neuem Code, dass Komponententests zusammen mit dem Funktionscode übermittelt werden. Bestimmte Dinge werden nur allzu leicht aufgeschoben.

Bei der Überprüfung von Codeänderungen sind unter Umständen neue oder überarbeitete Komponententests erforderlich. Führen Sie die vorhandenen sowie alle weiteren Komponententests durch, die mit der Codeüberprüfung übermittelt werden. Wenn die Komponententests nicht erfolgreich sind, bitten Sie den Autor, den Funktionscode und/oder die Komponententests zu aktualisieren, damit die Tests erfolgreich werden.

Suchen nach einer Parametervalidierung

Es ist sinnvoll, dass eine Methode ihre Eingabeparameter validiert. Wenn ein Parameter ungültig ist, sollte die Methode eine entsprechende Aktion ausführen. Ein Zeichenfolgenparameter sollte beispielsweise darauf überprüft werden, ob es sich um ein Null-Objekt handelt oder ob er String.Empty entspricht. In einer Situation, in der String.IsNullOrEmpty den Wert true zurückgibt, kann das Auslösen einer Ausnahme (beispielsweise eine ArgumentException oder eine ArgumentNullException) eine geeignete Aktion darstellen. In einer anderen Situation kehrt die Methode dagegen unter Umständen lediglich zum Aufrufer zurückkehren, ohne dass eine Aktion gestartet wird.

Suchen Sie bei der Überprüfung von Code nach Parameterwerten, die ein unerwünschtes Verhalten verursachen können. Die „schlechten“ Werte können so offensichtlich sein wie im oben abgebildeten Zeichenfolgenbeispiel. Sie können jedoch auch weniger offenkundig sein. Gehen Sie beispielsweise von einer Zeichenfolge aus, die numerische Daten zwischen 0,0 und 100,0 darstellen soll. Der Code führt möglicherweise eine zur Überprüfung auf NULL zusätzliche Validierung aus, beispielsweise das Entfernen von führenden oder nachstehenden Leerzeichen, die Umwandlung der Zeichenfolge in ein numerisches Format und die Validierung, dass sich der Wert im erwarteten Bereich befindet.

Kommentare

Erforderliche XML-Elemente

Jede Klassendefinition und alle öffentlichen Mitglieder sollten über summary-XML-Tags für eine Beschreibung der Klasse oder des Mitglieds verfügen. Dies ermöglicht den Benutzern der Klasse, die Beschreibung bei der Bearbeitung von Code anzuzeigen. Das XML-Tag parameter ist unter Umständen ebenfalls erforderlich. In Visual Studio 2005 fügen die Code-Editoren für C# und VB automatisch die Tags summary und parameter ein, wenn Sie /// bzw. ''' in einer Leerzeile über der Klassen- oder Methodendefinition eingeben. Dies ist äußerst nützlich, weil Sie die XML-Tagdefinitionen nicht korrekt eingeben müssen. Sie müssen nur die Beschreibungen eingeben.

Wenn Ihr Team kompliziertere XML-Header für Klassen- oder Mitgliederdefinitionen verwendet (einige Teams verlangen beispielsweise XML-Header, die den Änderungsverlauf einschließlich einer Beschreibung der Änderung, des Autors und der Datumsinformationen beinhalten), überprüfen Sie, ob die Header vorhanden sind und geeignete Daten eingegeben wurden.

Überprüfen aller XML-Elemente

Stellen Sie sicher, dass alle XML-Elemente wohlgeformt sind. Dies ist wichtig, da die Tools, die XML-Kommentare in Quellcode verarbeiten, wohlgeformte XML-Elemente benötigen, um korrekt zu funktionieren.

Entfernen Sie alle automatisch generierten leeren XML-Elemente, wenn sie von Ihrem Team nicht benötigt werden. VB generiert beispielsweise automatisch returns- und remarks-Elemente, die in vielen Fällen gelöscht werden können.

Zusätzliche Kommentare

Überprüfen Sie, ob der Code über ausreichend zusätzliche Kommentare verfügt, um die Verwendung, die Logik oder das Verhalten der Codeelemente zu beschreiben.

Qualität der Kommentare

Kommentare müssen klar sein und den zugehörigen Code genau beschreiben. Es gibt mehrere häufige Situationen, in denen Kommentare nicht mit dem Code übereinstimmen. Seien Sie auf diese Situationen vorbereitet. Wenn beispielsweise vorhandener Code in einem Modul geändert wird, wird die Aktualisierung der Kommentare manchmal übersehen. Oder wenn ein Codeabschnitt aus einer anderen Anwendung für einen aktuellen Zweck angepasst wird, sind die Kommentare des ursprünglichen Codes möglicherweise nicht mehr geeignet oder korrekt.

Zeichenfolgenkonstanten

Zeichenfolgenressourcendateien

Zeichenfolgenliterale sollten in einer Zeichenfolgenressourcendatei verpackt werden. Diese sammelt die Zeichenfolgen an einem Ort, sodass Änderungen am Zeichenfolgentext einfacher sind. Die Verwendung von Zeichenfolgenressourcendateien ermöglicht außerdem die Lokalisierung und Globalisierung. Das Erstellen und Verwenden von Zeichenfolgenressourcendateien war bislang relativ umständlich. Das Resource Refactoring Tool kann diese Aufgabe jedoch vereinfachen, zumindest für C#- und VB-Projekte. Die Zeichenfolgenliterale in der folgenden Anweisung:

private static string snippetSchemaPathBegin = 
Path.Combine(Environment.ExpandEnvironmentVariables("%ProgramFiles%"), 
@"\Microsoft Visual Studio 8\Xml\Schemas");

können mithilfe des Resource Refactoring Tool schnell in Folgendes geändert werden:

private static string snippetSchemaPathBegin = 
Path.Combine(Environment.ExpandEnvironmentVariables( 
Strings.ProgramFiles), Strings.MicrosoftVisualStudio8XmlSchemas);

Dateinamen und Pfade

Suchen Sie bei der Überprüfung von Code nach Zeichenfolgenliteralen oder Verweisen für Zeichenfolgenressourcendateien, die hartcodierte Dateipfade enthalten. Verwenden Sie stets Umgebungsvariablen, .NET-APIs, die einen Pfadnamen bereitstellen (beispielsweise System.Windows.Forms.Application.ExecutablePath, die den Pfad für die ausführbare Datei zurückgibt, die die Anwendung gestartet hat), oder einen Konfigurationsdateieintrag zu Verweispfaden. Dateien werden häufig auf anderen Laufwerken als C installiert, und der Installationsspeicherort wird auf andere Art und Weise angepasst.

Die Anwendungsdateinamen sollten ebenso nicht in einem Zeichenfolgenliteral oder einem Verweis für Zeichenfolgenressourcendateien definiert werden. Akzeptable Alternativen sind eine Konfigurationsdatei, Umgebungsvariablen oder Eingaben durch den Benutzer, wie z. B. ein Parameter zu einer Konsolenanwendung oder ein Dateidialogfeld in einer WinForms-Anwendung. Alle diese Alternativen ermöglichen dem Benutzer mehr Flexibilität bei der Verwendung Ihrer Anwendung.

Das folgende Beispiel zeigt mehrere ungeeignete Methoden, einschließlich einem hartcodierten Pfad und einer öffentlichen Variablen.

     public static readonly string SnippetSchemaPathBegin = 
@"C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas\";

Die Anweisung könnte mithilfe einer öffentlichen Eigenschaft und der SystemDrive-Umgebungsvariablen, wie hier gezeigt, neu geschrieben werden.

        public string SnippetSchemaPathBegin { get { return 
snippetSchemaPathBegin; } }
        private static string snippetSchemaPathBegin = 
Environment.ExpandEnvironmentVariables("%SystemDrive%" + @"\Program 
Files\Microsoft Visual Studio 8\Xml\Schemas");

Ähnlich dazu könnte die ProgramFiles-Umgebungsvariable, wie hier gezeigt, verwendet werden.

        private static string snippetSchemaPathBegin = 
Path.Combine(Environment.GetEnvironmentVariable("ProgramFiles"), 
@"Microsoft Visual Studio 8\Xml\Schemas");

Namenskonventionen

Namen

Im Allgemeinen müssen Namen lesbar sein und das Element klar beschreiben. Suchen Sie aus diesem Grund bei Codeüberprüfungen nach Abkürzungen in Namen, Kurznamen oder nicht beschreibenden Namen. Es ist sinnvoll, Funktions- und Methodennamen mit einem Verb zu beginnen, um die Aktion zu kennzeichnen, die sie für ihre Objekte durchführen. Ähnlich dazu sollten Variablennamen und Eigenschaftennamen Substantive sein, da es sich hierbei um Objekte handelt. Wenn Sie beispielsweise eine Klasse für Ebenengeometrieobjekte (wie einen Kreis) schreiben würden, können Sie Eigenschaften mit den Namen CenterPoint und Radius definieren. Funktionsnamen für eine solche Klasse können CalculateCircumference und CalculateArea sein.

Fallkonventionen in Namen

Stellen Sie sicher, dass der Quellcode die Fallkonventionen einhält, die im Abschnitt Capitalization Styles (auf Englisch) der Dokumentation zu Namensrichtlinien (siehe Verweis weiter oben in diesem Artikel) empfohlen werden. Mit anderen Worten, verwenden Sie camelCasing (der erste Buchstabe des Namens ist klein geschrieben, und der erste Buchstabe jedes weiteren Worts im Namen ist groß geschrieben) für Parameter, lokale Variablen und die privaten oder geschützten Variablen einer Klasse. Verwenden Sie PascalCasing (der erste Buchstabe jedes Worts im Namen ist groß geschrieben) für alle anderen Elemente, einschließlich Klassennamen, Methoden, Eigenschaften, Typdeklarationen und Enumerationswerte.

Ungarische Notation

Ungarische Notation wird für verwalteten Code nicht empfohlen. Die korrekte Verwendung von ungarischer Notation ist schwierig, und ungarische Notation ist schwer lesbar. Die Schwierigkeiten beim Lesen ungarischer Notation können außerdem die Logik verschleiern. Manche Programmierer haben sich die Verwendung ungarischer Notation beim Programmieren von C oder C++ zur Gewohnheit gemacht. Bedenken Sie dies bei Codeüberprüfungen.

Ausnahmen

Auslösen von Ausnahmen

Wenn der Code eine Ausnahme auslöst, stellen Sie sicher, dass der Ausnahmetyp geeignet ist, und dass die Nachricht klar das Problem identifiziert, das den Code zur Auslösung einer Ausnahme veranlasst hat. Fügen Sie der Ausnahmenachricht so viele Debuginformationen wie möglich hinzu. Dies hilft bei der Diagnose des Problems, entweder über eine Stapelüberwachung oder eine Protokolldatei.

Abfangen von Ausnahmen

Wenn durch den zu überprüfenden Code eine Methode aufgerufen wird, die wahrscheinlich eine Ausnahme auslösen wird, stellen Sie sicher, dass der Code die Ausnahme korrekt verarbeitet. File.Open kann beispielsweise mehrere übliche Ausnahmen auslösen, einschließlich FileNotFoundException und UnauthorizedAccessException. Es empfiehlt sich, diese Ausnahmen abzufangen und dem Benutzer eine Fehlermeldung anzuzeigen.

Definieren von Ausnahmen

Wenn der Code für eine Assembly Ausnahmen definiert, definieren Sie die am häufigsten verwendeten Typen in einer globalen Ausnahmeklasse für die Assembly. Definieren Sie Ausnahmen, die speziell für eine bestimmte Klasse gelten, in der Klasse selbst.

Formatierung

Verwenden Sie Regionen für die Organisation von Code

Achten Sie bei der Überprüfung von Code auf die Verwendung von Regionen, um die Lesbarkeit des Codes zu verbessern. Regionen werden häufig nicht hinreichend, manchmal aber auch in zu großem Maße verwendet.

Regionen helfen bei der logischen Organisation von Code und verbessern die Lesbarkeit großer Dateien, da Sie nicht benötige Regionen reduzieren und nur den Teil des Codes anzeigen können, den Sie zurzeit benötigen. Das Reduzieren von Regionen erleichtert außerdem das Durchblättern großer Dateien, um eine gewünschte Region zu finden. Seien Sie jedoch vorsichtig bei der Verwendung verschachtelter Regionen. Die Reduzierung einer äußeren Region kann die inneren Regionen verdecken und das Finden einer gewünschten Region erschweren.

Regionen werden häufig um die privaten Daten einer Klasse, um Konstruktoren, öffentliche Eigenschaften, private Methoden und öffentliche Methoden herum verwendet. In einem Testprojekt werden Regionen häufig zur Gruppierung der Tests verwendet. Eine Region kann beispielsweise die Komponententests für eine der Methoden der Klasse gruppieren.

Verwenden Sie Leerzeilen zum Trennen von Definitionen

Die Verwendung von Leerzeilen zwischen Definitionen derselben Ebene verbessert die Lesbarkeit. Verwenden Sie jedoch nicht mehr als zwei Leerzeilen hintereinander.

Verschiedenes

Keine öffentlichen Variablen

Überprüfen Sie, ob die Datenvariablen einer Klasse als privat deklariert sind. Wenn Sie Zugriff auf die Daten erlauben, definieren Sie eine öffentliche oder geschützte Eigenschaft, um dem Benutzer Zugriff zu ermöglichen.

Rückgabewerte

Methoden, die einen Wert zurückgeben, müssen die Return-Anweisung verwenden, statt dem Methodennamen einen Wert zuzuweisen.

Keine GoTo-Anweisungen

GoTo-Anweisungen sind unnötig. Diese können gelegentlich unter besonderen Umständen verwendet werden. Sie sollten jedoch einen Großalarm auslösen, wenn sie in einer Codeüberprüfung auftreten.

Numerische Konstanten

Fast alle Debugtools zeigen numerische Konstanten standardmäßig hexadezimal an. Definieren Sie daher numerische Konstanten hexadezimal für Fenster-IDs, Steuerungs-IDs usw., sodass Sie sie während des Debuggens nicht von dezimal in hexadezimal konvertieren müssen.

Schlussbemerkung

In diesem Dokument wurden Standardverfahren für die Überprüfung von verwaltetem Code beschrieben. Einige dieser Methoden gelten für die Überprüfung von verwaltetem und nicht verwaltetem Code. Andere sind speziell auf die Überprüfung von verwaltetem Code anwendbar.


Anzeigen:
© 2014 Microsoft