Bewertung: 4.8 von 5 Benutzern
klaus_b
Mit Microsoft Source Analysis for C#, aka StyleCop, wurde ein weiteres Werkzeug zur Codeanalyse freigegeben. Im Gegensatz zu FxCop, der den IL-Code analysiert, untersucht Source Analysis den Quellcode. Das Tool wird als VS-AddIn oder während des Build-Vorgangs verwendet. Da ich nur die C# Express Version besitze, kam für mich nur die Verwendung im Build-Prozess in Frage. Wie Source Analysis in den Build-Prozess eingebunden wird, ist sehr ausführlich in diesem Blog Artikel beschrieben. An das UI von Source Analysis kommt man in der Express Edition nicht so schön heran wie in Visual Studio Standard oder Professional. Aber dafür gibt es in den Express Editions unter Extras den Menüpunkt Externe Tools. Hier kann nun die SourceAnalysisSettingsEditor.exe mit der Einstellungsdatei Settings.SourceAnalysis als Parameter eingetragen werden. Hier ein ScreenShot wie der Menüeintrag aussehen sollte.
Da ich nicht für jedes Projekt neue Einstellungen benötige, verwende ich nur die Einstellungen der Datei im Installationsordner von Source Analysis. Für Leute die in ihren Projekten unterschiedliche Einstellungen benötigen, kann hier mit den Argumenten, etwa dem Projektverzeichnis, von C# Express gearbeitet werden.
Nach dem der Menüpunkt jetzt zur Verfügung steht, können die Einstellungen von Source Analysis den eigenen Anforderungen angepasst werden. Ich kann allen die ihre Kommentare in deutsch ausführen nur empfehlen die Regel SA1623 zu deaktivieren. Diese Regel prüft den Kommentar von Eigenschaften ob dieser, je nach Accessor, mit Get's oder Set's beginnt. Macht ja im deutschen wenig Sinn.
Wer eigene Regeln verwenden will findet in diesem Blog eine recht ausführliche Anleitung um Bibliotheken mit eigenen Regeln für Source Analysis zu erstellen.
Nach dem Source Analysis das erste mal über eine Bibliothek gelaufen war, bekam ich große Augen. Ich dachte immer ich würde mich an die Entwurfsrichtlinien halten. Aber über 500 Warnungen sagen etwas anderes aus. Gut, zum größten Teil waren es Meldungen der Regel SA1027: Tabs are not allowed. Use spaces instead. Was Source Analysis auch gar nicht gefällt, sind private Felder die mit einem "_" beginnen. Auch die Regel SA1201: All properties must be placed after all constructors. wurde oft angezeigt. Bisher habe ich immer wie folgt strukturiert: private Felder, Eigenschaften, Konstruktoren, öffentliche Methoden und zum Schluss die privaten Methoden. War anscheinend falsch.
Für einzelne Personen wie mich ist es relativ einfach den Stiel zu ändern. Aber was ist mit großen Teams? Wer Interesse hat, kann sich einmal die Diskussionen zu Source Analysis zu Gemüte führen.
Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.
