Welche definierbare statische Code-Prüfregel möchten Sie zu FxCop und/oder Gendarme hinzugefügt sehen?Welche Regel wünschen Sie FxCop/Gendarme?
Warum möchten Sie die Regel hinzugefügt sehen, z. B. welche Vorteile usw.?
Wie könnte Ihre Regel implementiert werden?
Persönlich würde ich lieber nicht IDisposable Implementierungen in using Aussagen verwenden.
Also, wenn Sie Code wie folgt hatte:
var fs = new FileStream(...);
// Other code.
fs.Dispose();
Es würde Ihnen sagen, es in einer using Anweisung zu verwenden.
Der Vorteil wäre, dass Sie auf Fälle aufmerksam gemacht werden, in denen Sie möglicherweise nicht wissen, wo Objekte, die entsorgt werden sollten, nicht rechtzeitig entsorgt werden.
Es gibt jedoch genug Zeiten, in denen es eine gültige Situation ist, IDisposable Implementierungen in einer using-Anweisung für eine Regel wie diese nicht zu deklarieren, um sehr schnell ein Schmerz zu werden. In den meisten Fällen wird in diesem Fall eine IDisposable Implementierung als Parameter für eine Methode verwendet.
Was ich tun nicht bedeuten Verwendungen von Klassen ist, wo die Details der Implementierung die Notwendigkeit entfernen Dispose für den Aufruf (z MemoryStream oder DataContext); diese implementieren IDisposable und sollten immer Dispose aufgerufen haben, unabhängig von der Implementierung Details, wie es immer besser ist, gegen den Vertrag ausgesetzt Code.
@Ian Ringrose: Aktualisiert meine Antwort zu klären. – casperOne
VS2010 Code-Analyse hat eine non-break-Regel dafür: http://msdn.microsoft.com/en-us/library/ms182289%28VS.100%29.aspx –
Ich möchte meine eigenen Regeln sehr schnell definieren und implementieren. Ich habe das einmal für FxCop ausprobiert, aber ich fand die API nicht sehr klar - und es gab nicht viel Dokumentation. Ich benutzte FxCop 1,36, vielleicht änderten sich die Dinge ...
So würde Ich mag FxCop sehen, eine klare und mit leicht bedienbaren Oberfläche ... das wäre toll :)
Die Regeln Ich habe versucht, zu implementieren waren:
Bas Ich wollte XML-Kommentare für nicht-öffentliche Mitglieder erzwingen.
Verwenden Sie StyleCop für dieses, es hat eine Regel für das Builtin. XML-Kommentare werden sowieso nicht in die Assembly kompiliert, sodass der FXCop nicht sehen kann, ob diese definiert sind oder nicht, da er nur die kompilierten Assemblys analysiert. –
Ich kenne StyleCop, aber zu diesem Zeitpunkt wollte ich es in FxCop implementieren - und ich tat das. Du hast recht, du musst die xml-Dateien separat laden. – tanascius
Ich würde wirklich gerne die binäre Analyse schlau genug, um die Möglichkeit einer Schnittstelle zu erkennen.
Wenn es aus der Annäherung an die definierten Typen und deren Mitglieder feststellen könnte, ob es Commons gibt, die in eine Schnittstelle extrapoliert werden könnten.
Dies sollte natürlich nicht mehr als eine Warnung sein, da es manchmal erwünscht ist, explizit keine Schnittstelle zu verwenden.
Wenn ich darüber nachdenke, würde ich auch gerne sehen, dass die binäre Analyse schlau genug ist, um eine mögliche Herabstufung von Zugriffsmodifizierern zu überprüfen.
Es sollte nicht schwer zu bestimmen sein, ob eine Klasse, Eigenschaft oder Methode eingeschränkt sein könnte.
FXCop führt keine statische Codeüberprüfung durch, es überprüft die kompilierte Assembly (IL). Statische Code-Analyse wird über StyleCop durchgeführt. –
@BeowulfOF, ich würde sagen, dass FXCop statische Codeüberprüfung gemacht hat, es überprüft einfach nicht die Anzahl der Leerzeichen, die Sie auf jeder Seite eines "=" usw. haben. StyleCop prüft mehr Stil, z. ID verfolgt keinen Kontrollfluss zwischen Methoden usw. –
Microsoft gibt an, dass nur Baugruppen von FXCop analysiert werden, nicht der Quellcode. http://msdn.microsoft.com/en-us/library/bb429476%28VS.80%29.aspx –