Ich erstelle Klassenbibliotheken, einige, die von anderen auf der ganzen Welt benutzt werden, und jetzt, wo ich Visual Studio 2010 benutze, frage ich mich, wie gut es für mich ist, auf Codeverträge umzusteigen, anstatt regelmäßige if-Anweisungen im alten Stil.
ie. Statt dessen:
%Vor%benutze dies:
%Vor%Der Grund, warum ich frage, ist, dass ich weiß, dass der statische Checker für mich nicht verfügbar ist, also bin ich etwas nervös wegen einiger Annahmen, die der Compiler nicht überprüfen kann. Dies kann dazu führen, dass die Klassenbibliothek für jemanden, der sie lädt, nicht kompiliert wird, wenn sie den statischen Checker haben. Dies, gepaart mit der Tatsache, dass ich das Problem nicht einmal reproduzieren kann, würde es ermüdend machen, es zu beheben, und ich würde sagen, dass es keine Bände über die Qualität meiner Klassenbibliothek spricht, wenn es scheinbar nicht einmal aus der Box.
Ich habe also ein paar Fragen:
Jeder Rat wäre willkommen.
Bearbeiten Lassen Sie mich klarstellen, was ich meine.
Sagen wir, ich habe die folgende Methode in einer Klasse:
%Vor%und dann habe ich diesen Code:
%Vor%Nun, hier tritt IoC ein, löst eine "zufällige" Klasse auf, die mir einen Dateinamen liefert. Nehmen wir an, dass es für diese Bibliothek keine Möglichkeit gibt, eine Klasse zurück zu bekommen, die mir keinen Nicht-Null-Dateinamen geben wird. Aufgrund der Art des IoC-Aufrufs kann die statische Analyse dies jedoch nicht überprüfen und könnte daher annehmen, dass ein möglicher Wert könnte null sein.
Daher könnte die statische Analyse zu dem Schluss kommen, dass die LogToFile -Methode mit einem null -Argument aufgerufen wird und somit nicht aufgebaut werden kann.
Ich verstehe, dass ich dem Code Annahmen hinzufügen kann, indem ich sage, dass der Compiler es als gegeben annehmen sollte, dass das fileName , das ich von dieser Methode zurückerhalte, nie null ist, aber wenn ich kein statisches Analysegerät habe ( VS2010 Professional), würde der obige Code für mich kompilieren, und so könnte ich dies als einen Schlaffehler für jemanden mit Ultimate zu finden. Mit anderen Worten, es gibt keine Kompilierungszeitwarnung, dass es hier ein Problem geben könnte, also könnte ich die Bibliothek so wie sie ist freigeben.
Also ist das ein echtes Szenario und Problem?
Wenn sowohl Ihre LogToFile als auch Log Methoden Teil Ihrer Bibliothek sind, ist es möglich, dass Ihre Log -Methode nicht kompiliert wird, sobald Sie die statische Überprüfung aktiviert haben. Dies passiert natürlich auch, wenn Sie Code an andere weitergeben, die Ihren Code mit dem statischen Checker kompilieren. Soweit ich weiß, validiert der statische Checker Ihres Clients jedoch nicht die Interna der Assembly, die Sie versenden. Es überprüft den eigenen Code statisch auf die öffentliche API Ihrer Assembly. Solange Sie nur die DLL versenden, wäre alles in Ordnung.
Natürlich gibt es eine Änderung des Versands einer Bibliothek, die eine sehr lästige API für Benutzer hat, die tatsächlich den statischen Checker aktiviert haben. Daher denke ich, dass es ratsam ist, Ihre Bibliothek nur mit den Vertragsdefinitionen zu versenden, wenn Sie die Benutzerfreundlichkeit testen der API sowohl mit als auch ohne den statischen Checker.
Bitte beachten Sie, dass Sie die vorhandenen Aufrufe von if (cond) throw ex in Contracts.Requires(cond) für öffentliche API-Aufrufe ändern, die Sie bereits in einer früheren Version ausgeliefert haben. Beachten Sie, dass die Requires -Methode eine andere Ausnahme auslöst (ein RequiresViolationException , wenn ich mich richtig erinnere) als das, was Sie normalerweise werfen würden (a ArgumentException ). Verwenden Sie in diesem Fall die Contract.Requires -Überlastung. Auf diese Weise bleibt Ihre API-Schnittstelle unverändert.
Erstens ist der statische Checker wirklich (wie ich es verstehe) nur in den ultimativen / akademischen Editionen verfügbar. Wenn also nicht jeder in Ihrer Organisation ihn verwendet, werden sie möglicherweise nicht gewarnt, wenn sie potentiell verletzen eine Invariante.
Zweitens, während die statische Analyse beeindruckend ist, kann sie nicht immer alle Pfade finden, die zur Verletzung der Invarianten führen können. Die gute Nachricht hier ist jedoch, dass der Requires Vertrag zur Laufzeit beibehalten wird - er wird in einem IL-Transformationsschritt verarbeitet - also existiert die Überprüfung zu beiden Kompilierungszeiten und Laufzeit. Auf diese Weise ist es äquivalent (aber überlegen) zu einem normalen if() Check.
Sie können mehr über das Umschreiben der Laufzeit lesen, das die Kompilierung von Code-Kontrakten ausführt. hier , können Sie auch die ausführliches Handbuch hier .
BEARBEITEN: Basierend auf dem, was ich aus dem Handbuch entnehmen kann, vermute ich, dass die von Ihnen beschriebene Situation tatsächlich möglich ist. Ich dachte jedoch, dass dies eher Warnungen als Kompilierungsfehler sind - und Sie können sie mit System.Diagnostics.CodeAnalysis.SuppressMessage() unterdrücken. Verbraucher Ihres Codes, die den statischen Verifizierer haben, können auch bestimmte Fälle kennzeichnen, die ignoriert werden sollen - aber das könnte sicherlich unbequem sein, wenn es viele von ihnen gibt. Ich werde heute versuchen, etwas Zeit später zu finden, um einen endgültigen Test Ihres Szenarios zu erstellen (ich habe im Moment keinen Zugang zum statischen Verifizierer).
Es gibt einen exzellenten Blog hier , der fast ausschließlich für Code-Verträge gedacht ist (falls nicht noch gesehen) kann einen Inhalt haben, der Sie interessiert.
Tags und Links visual-studio-2010 c#-4.0 code-contracts static-analysis