Statische Code-Analyse

Wie wir statische Code-Analyse in unseren .NET Projekten einsetzen

Gepostet von Sandro C. am 19.05.2020

.Net QS Code-Analyse Nuget Roslyn

Im Rahmen unserer Qualitätssicherung setzen wir unter anderem auf statische Code-Analyse. Damit ist es möglich, Fehler im Entwicklungsprozess bereits früh zu erkennen und zu korrigieren. So legen wir auch den Grundstein der Evolvierbarkeit bzw. Wartbarkeit, die im Lebenszyklus einer Software oft über die Hälfte des gesamten Aufwands ausmachen kann.

Für fast alle Sprachen sowie Technologien und somit auch für C# und .NET gibt es heute Werkzeuge für die statische Code-Analyse. Die Konfiguration und vor allem die Integration dieser Werkzeuge in den täglichen Entwicklungsprozess war allerdings lange nicht gerade trivial. Mit der Veröffentlichung und Etablierung von Roslyn und NuGet im .NET-Ökosystem hat sich das aber deutlich geändert. Die Werkzeuge müssen nicht mehr auf den einzelnen Computern der Entwickler installiert werden, sondern lassen sich zusammen mit dem Code als sogenannte Analyzer herunterladen und dank Roslyn direkt bei der Kompilierung ausführen.

Die Funktionsweise der Analyzer ist simpel: Probleme im Quellcode sind oft auf bestimmte Muster zurückzuführen, die Softwareentwickler beim Programmieren oft unbewusst benutzen . Die Hersteller von Analyzern formulieren diese Muster als klar definierte Regeln und geben jeder eine ID. Wird im Quellcode gegen eine solche Regel versto ssen, weil z. B. ein Muster benutzt wurde, das als problematisch bekannt ist, erteilt der Analyzer eine Warnung an den Entwickler.

Wir haben ein firmeninternes NuGet Paket erstellt, das drei verschiedene Analyzer enthält:

StyleCop analysiert den Quelltext noch vor dem Kompilieren und zielt darauf ab, dass dieser möglichst einheitlich formatiert und formuliert ist. StyleCop meldet sich auch dann, wenn Entwickler vergessen, Klassen oder Methoden zu dokumentieren.

FxCop analysiert den kompilierten Quelltext auf mögliche Probleme, die während der Laufzeit auftauchen können. Probleme können unteranderem Speicherüberläufe, schlechte Portabilität, Sicherheits- und Performanceprobleme oder Formatierungsprobleme aufgrund der Verwendung verschiedene Sprachen und Ländern sein.

SonarSource analysiert sowohl unkompilierten wie auch kompilierten Quellcode. SonarSource hat im Gegensatz zu StyleCop und FxCop seine Ursprünge nicht bei Microsoft und entwickelt auch Analyzer für diverse andere Programmiersprachen. Daher konzentriert sich SonarSource vor allem auf allgemeine Probleme, die auch bei der Verwendung von nicht Microsoft-basierten Technologien auftauchen.

In unserem NuGet Paket wird ein von uns intern definierter Regelsatz mitgeliefert, der festlegt, welche Regeln wir im Quellcode geprüft haben möchten und welche nicht. So haben wir in jedem Neolution-Projekt die gleichen Regeln und können diesen Regelsatz sowie die Analyzer jederzeit selbst über NuGet aktualisieren, falls es Änderungen oder Aktualisierungen gibt.