Wie implementiert man FxCop/statische Analyse auf einer vorhandenen Codebasis?

Question

Welche Strategien werden bei der Implementierung von FxCop/statischer Analyse auf vorhandenen Codebasen mit bestehenden Verstößen verwendet?Wie kann man die Verstöße gegen die statische Analyse am effektivsten reduzieren?

Answer 1

Machen Sie zunächst großzügigen Gebrauch vom Attribut [SuppressMessage].Zumindest am Anfang.Sobald Sie die Anzahl über das Attribut auf 0 gesetzt haben, legen Sie eine Regel fest, die verhindert, dass neue Check-ins zu FxCop-Verstößen führen.

Visual Studio 2008 verfügt über eine praktische Codeanalysefunktion, mit der Sie sicherstellen können, dass die Codeanalyse bei jedem Build ausgeführt wird, und Warnungen als Fehler behandeln können.Das könnte die Dinge etwas verlangsamen, daher empfehle ich, einen Continuous-Integration-Server (wie CruiseControl.NET) einzurichten und ihn bei jedem Check-in eine Codeanalyse durchführen zu lassen.

Sobald Sie es unter Kontrolle haben und nicht bei jedem Einchecken neue Verstöße einführen, beginnen Sie damit, jeweils ganze Klassen von FxCop-Verstößen anzugehen, mit dem Ziel, die von Ihnen verwendeten SuppressMessageAttributes zu entfernen.

Um den Überblick darüber zu behalten, welche Sie wirklich behalten möchten, fügen Sie denjenigen, die Sie wirklich unterdrücken möchten, immer einen Begründungswert hinzu.

Answer 2

Schreiben Sie Ihren Code im vorübergehenden Stil um!

Im Ernst, eine alte Codebasis wird Hunderte von Fehlern enthalten – aber deshalb haben wir Programmieranfänger/-praktikanten.Das Korrigieren von FxCop-Verstößen ist eine hervorragende Möglichkeit, sich einen Überblick über die Codebasis zu verschaffen und auch zu lernen, wie man konformen .NET-Code schreibt.

Also beißen Sie einfach in den sauren Apfel, trinken Sie viel Koffein und schaffen Sie es in ein paar Tagen!

Answer 3

NAbhängig sieht aus wie Es könnte tun, was Sie suchen, aber ich bin mir nicht sicher, ob es in einen automatisierten CruiseControl.Net-Build integriert werden kann und der Build fehlschlägt, wenn der Code die Anforderungen nicht erfüllt (was ich gerne tun würde). passieren).

Irgendwelche anderen Ideen?

Answer 4

Eine Alternative zu FxCop wäre die Nutzung des Tools NAbhängig.Mit diesem Tool können Sie schreiben Coderegeln für C#-LINQ-Abfragen (wie wir es nennen CQLinq). Haftungsausschluss:Ich bin einer der Entwickler des Tools

Mehr als 200 Coderegeln werden standardmäßig vorgeschlagen.Das Anpassen bestehender Regeln oder das Erstellen eigener Regeln ist dank des einfach sehr bekannt C# LINQ-Syntax.

Um die Anzahl falsch-positiver Ergebnisse gering zu halten, bietet CQLinq die einzigartigen Funktionen zur Definition der Menge JustMyCode durch spezielle Codeabfragen mit dem Präfix notmycode.Weitere Erläuterungen zu dieser Funktion finden Sie hier Hier.Hier sind zum Beispiel zwei notmycode Standardabfragen:

• Verwerfen Sie generierte und Designer-Methoden von JustMyCode
• Verwerfen Sie generierte Typen von JustMyCode

Um die Anzahl falsch-positiver Ergebnisse gering zu halten, können Sie mit CQLinq die Regelergebnisse auch nur auf hinzugefügten oder umgestalteten Code konzentrieren, da a definierte Grundlinie in der Vergangenheit.Sehen Sie sich die folgende Regel an, die zu komplexe Methoden erkennt, die seit der Baseline hinzugefügt oder umgestaltet wurden:

warnif count > 0 
from m in Methods
where m.CyclomaticComplexity > 20 &&
      m.WasAdded() || m.CodeWasChanged()
select new { m, m.CyclomaticComplexity }

Beachten Sie abschließend, dass mit NDepend Coderegeln überprüft werden können live in Visual Studio und zum Zeitpunkt des Build-Prozesses, in a generierter HTML+Javascript-Bericht.