Kurz vor Ostern erhielt ich von Patrick Smacchia, dem verantwortlichen Entwickler hinter NDepend, eine Anfrage, ob ich Interesse hätte mir NDepend einmal anzusehen. Die eingeholten Vorabinformationen aus der deutschen .NET-Gemeinde waren durchweg positiv und erzeugten eine gewisse Neugier. Warum also nicht eine eigene Meinung bilden?
Ich bekundete mein Interesse beim NDepend-Team und erhielt kurz darauf eine Lizenz. Der Download fällt mit 9,4 MB eher klein aus. Eine echte Installation wird nicht benötigt. Es müssen lediglich die Daten aus dem ZIP-Archiv in ein privates Verzeichnis entpackt werden. Das entpacken der Daten in den Programmeordner sollte wegen möglicher Probleme mit der Benutzerkontensteuerung (UAC) unterbleiben. Nach dem Entpacken muss, für die Integration von NDepend in Visual Studio, einmal die Anwendung NDepend.Install.VisualStudioAddin.exe ausgeführt werden. In einem Auswahldialog wird nach der verwendeten Visual Studio Version gefragt. Es kann zwischen voller Integration und einer, Light Integration genannten, teilweisen Integration gewählt werden. Die von NDepend verwendeten Shortcuts können auf Wunsch deaktiviert werden, falls Kollisionen mit bereits verwendeten Tastenkürzeln zu befürchten sind. Ab jetzt steht NDepend zur Codeanalyse in Visual Studio zur Verfügung.
Um NDepend mit einem Visual Studio Projekt zu verwenden, kann entweder eine neues NDepend-Projekt erzeugt und mit dem aktuellen Visual Studio-Projekt verknüpft, oder das aktuelle Visual Studio-Projekt mit einem bestehenden NDepend-Projekt verknüpft werden.
Auf der Seite der Einstellungen des NDepend-Projekts, ist der wichtigste Punkt die richtige Auswahl der zu verwendenden Framework-Version.
Mit dieser Einstellung wir festgelegt, aus welchen Ordnern NDepend die referenzierten Assemblies des Framework lädt. Die weiteren Einstellungen, etwa zur Analyse und zum Aussehen des erzeugten Reports, sind selbsterklärend.
Nach der ersten Analyse des aktuellen Projekts, steht in der linken unteren Ecke in Visual Studio ein kleiner farbiger Kreis zur Verfügung, der den aktuellen Status der Analyse des Projekts anzeigt. Es werden die Ampelfarben Rot, Gelb und Grün, sowie Grau und Blau mit folgender Bedeutung verwendet:
Rot
- Eine oder mehrere der als kritisch eingestuften Regeln wurde verletzt
- Eine oder mehrere der aktivierten Regeln kompiliert nicht
- Eine oder mehrere der aktuellen Abfragen ist fehlerhaft.
Gelb
Eine oder mehrere der aktivierten Regeln wurde verletzt.
Grün
Es wurde keine der aktivierten Regeln verletzt.
Grau besagt, dass kein NDepend-Projekt zur Verfügung steht.
Blau wird angezeigt, während eine Analyse ausgeführt wird.
Beim Überfahren des Symbols mit der Maus wird ein Menü sichtbar. In diesem Menü können, unter anderem, die Einstellungen zur Ausführung der Analyse sowie zur Aktualisierung der Analyse in Visual Studio fein eingestellt werden.
Es kann auch eine Analyse des aktuellen Projekts direkt angestoßen werden.
Im oberen Bereich wird der aktuelle Status des Projekts in einer Zusammenfassung gezeigt.
Den Kern der Analyse bildet die in NDepend integrierte Code Query Language (CQL). Dies Abfragesprache erinnert stark an SQL und ist auch sehr ähnlich zu verwenden. Zum Bearbeiten bestehender Abfragen oder um neue Regeln zum aktuellen Projekt hinzuzufügen, steht ein integrierter Editor zur Verfügung. Mit diesem Konzept und dem integrierten Editor ist es sehr einfach, bestehende Regeln den aktuellen Anforderungen anzupassen oder neue Regeln zu erstellen.
Eine der Regeln besagt:
Felder welche auf die Bezeichnung Uri enden, sollten vom Typ System.Uri sein.
Es kann aber wie in folgendem Beispiel vorkommen, dass der Namensteil Uri verwendet wird aber dennoch der Typ Uri nicht verwendet werden kann. Zum Beispiel ein Feld vom Typ ConfigurationProperty mit dem Namen serviceUri würde diese Regel verletzen. Mit dem integrierten CQL-Editor wird einfach als optionales Kriterium
nicht vom Typ ConfigurationProperty
zur Abfrage hinzugefügt.
Die jeweiligen Änderungen oder Anpassungen des Regelwerks sind allerdings nur für das aktuelle Projekt gültig. Ich habe noch keinen Weg gefunden, um allgemeingültige Änderungen des Regelwerks vorzunehmen.
NDepend analysiert nicht den Quellcode, sondern den erzeugten IL-Code in den kompilierten Assemblies. Um die jeweiligen Stellen im Quellcode zeigen zu können, werden Debug-Assemblies mit der zugehörigen PDB-Datei benötigt. Eine Analyse von Assemblies mit Release-Status ist nicht vorgesehen.
Soweit zur Arbeits- und Funktionsweiße.
Als erstes Projekt zur Analyse mit NDepend habe ich mir eine kleine Anwendung ausgesucht, die als Modul in ASP.NET Anwendungen zum Einsatz kommt. Die Anwendung hat kein UI, wird ausschließlich über die web.config konfiguriert und von einem Http-Modul gestartet.
Der erste Report brachte eine Fülle von Informationen und jede Menge Warnungen zu Tage. Die für mich interessanteste Warnung betraf die Sichtbarkeit des verwendeten Http-Moduls, der enthaltenen Http-Handler und der Klasse der Einstellungen die von ConfigurationSection abgeleitet ist. NDepend empfahl diese Klassen als internal zu deklarieren.
Und wie soll dann bitte die Webanwendung auf diese Typen zugreifen? Egal; das wollte ich wissen. Ich deklarierte also die betreffenden Klassen als internal, kompilierte das Projekt im Release-Status neu und startete eine Webanwendung in der ich das Modul verwendete. Zu meiner großen Überraschung funktionierte alles wie gewohnt. Mit dem positiven Nebeneffekt, dass ich keine öffentliche API mehr zur Verfügung stellte die auch so nie vorgesehen war. OK. Wieder etwas dazugelernt.
NDepend ist auch das erste, mir bekannte, Analyse-Tool welches auf die Unveränderbarkeit von Strukturen (immutable struct) achtet. Hier wird geprüft, ob auch wirklich alle Felder der Struktur als readonly deklariert sind. Dadurch wurde ich angehalten, mich mit der Implementierung von entsprechenden Replace-Methoden in solche unveränderliche Strukturen zu befassen.
Aber das ist ein anderes Thema.
Im Allgemeinen sind die Standard-Regeln bereits sehr restriktiv ausgelegt. Wenn sie befolgt und nicht umgangen werden, resultiert aus der konsequenten Anwendung ein deutlich wartbarerer Code.
NDepend kann natürlich noch deutlich mehr als ich hier in ein paar wenigen Zeilen schreiben kann. Ich werde nach und nach, wenn ich NDepend etwas besser kenne, auf die einzelnen Feature eingehen.
Fazit:
NDepend erscheint mir als ein hilfreiches Werkzeug, sehr gut geeignet zur täglichen Verwendung. Die Entwickler hinter NDepend leisten sehr gute Unterstützung bei eventuellen Problemen und helfen schnell und unkompliziert.
Bei meinen Recherchen vor der Verwendung von NDepend, sagte mit einer der Gefragten eine steile Lernkurve mit NDepend voraus. Dem kann ich mich nur anschließen.
Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.
