Top 10 Fehler–#11: Neglecting FxCop/Static Code Analysis

27. August 2014

Dies ist Teil 12 der kleinen Serie, die ich als Kommentar zum Blog-Beitrag Top 10 Mistakes that C# Programmers Make begonnen habe.

Und mittlerweile bin ich bei den Themen angekommen, die mir in der Liste noch fehlen. 11 von 10 ist also kein Fehler ;-)…

 

AJ’s Common Mistake #11: Neglecting FxCop/Static Code Analysis

Es zieht sich wie ein roter Faden durch viele von Patrick’s “Common Mistakes”, wurde aber von ihm nie explizit adressiert: FxCop bzw. die in Visual Studio eingebaute Variante Code Analysis würde helfen!

Der Compiler kann Warnungen liefern wenn es um typische Fallen auf Sprachebenen geht, leere Anweisungen weil ein Semikolon zu viel gesetzt wurde und ähnliches. Aber sobald es um die korrekte Verwendung von Methoden geht, um Code-Idiome und Patterns, um Prüfungen von Randbedingungen etc., schlägt die Stunde von Werkzeugen zur statischen Code-Analyse, speziell FxCop.

Merker: Es gibt keinen Grund, FxCop nicht einzusetzen! Aber viele Gründe das zu tun!

Man sollte das auch von Anfang an tun; FxCop einzuschalten wenn ein Projekt schon einige Zeit entwickelt wurde führt häufig zu einer Flut von Fehlermeldungen.

Worüber man durchaus zumindest kurz nachdenken sollte ist die Frage, wie FxCop eingesetzt werden soll, sprich mit welchen Regeln. Selbst Microsoft bietet von sich aus schon unterschiedliche Regel-Sets an. Und in der Voreinstellung ist Microsoft hier (leider) sehr zögerlich. Die voreingestellten Managed Recommended Rules kann man sich nach meiner Erfahrung auch sparen. Selbst klassische Fehler, wie Enums ohne 0-Wert werden damit nicht geprüft. Andererseits sind “Microsoft All Rules” dem einen oder anderen dann vielleicht doch etwas zu viel des Guten. Bleibt die Definition eines eigenen Regelsets. Genau das wird aber seit Visual Studio sehr gut unterstützt.

Und wem das noch nicht reicht, der kann das Thema auch noch weiter ausreizen: