Entzaubertes LINQ

LINQ steht schon seit C# 3.0 beziehungsweise Visual Studio 2008 .NET-Entwicklern zur Verfügung. Die Bezeichnung ist eine Abkürzung für Language Integrated Query. Ziel der Technologie ist, den Zugriff auf Daten innerhalb von C# deutlich zu vereinfachen. Ohne LINQ kann das mitunter recht aufwändig werden. Da kämen verschachtelte Schleifen und irre if-Abfragen ins Spiel – Codeabschnitte, die immens schlecht lesbar sind. Mithilfe von LINQ lassen sich solche Aufgaben deutlich kompakter lösen.

LINQ kann auf zwei Wegen im Code verwendet werden. Zum einen werden dessen Methoden hintereinander innerhalb eines Statements aufgerufen. Also ganz klassisch im Sinne eines Fluent-API. Zum anderen gibt es die sogenannte Query-Syntax, die eher an einen SQL-Ausdruck innerhalb von C# erinnert. Bei kleineren Abfragen gilt das Fluent API als kompakter und besser lesbar. Sind die Abfragen hingegen komplexer, kann die Query-Syntax mit Übersichtlichkeit punkten.

Die Suche nach einem Fehler gerät in beiden Fällen allerdings schnell zu einer Geduldsprobe. Die Debugging-Unterstützung von LINQ ist eher schlecht als recht. Zu häufig müssen Umwege in Kauf genommen werden, in dem zum Beispiel Teile der LINQ-Anweisung wieder in die imperativen Äquivalente umgewandelt werden. Die Entwickler von OzCode haben dieses Problem erkannt und bieten ein dediziertes Feature zum Debuggen von LINQ-Anweisungen an.

Hier tritt nun OzCode auf. Dieses Plug-in für Visual Studio hat sich das Vereinfachen des Debuggens auf die Fahnen geschrieben. Version 3.0 von OzCode [1] erschien zeitgleich mit Visual Studio 2017 und unterstützt diese Version der Entwicklungsumgebung.

Schon OzCode 2.x bot ein LINQ-Debugging an. Dort allerdings im Rahmen eines Early Access Program (EAP) [2]: Die Version mit diesem Feature musste explizit heruntergeladen werden. OzCode 3.0 hat das LINQ-Debugging nun vollständig integriert. Es ist mit einer Reihe von Visualisierern ausgestattet, die hilfreiche Informationen zu einer LINQ-Anweisung preisgeben. Wie von OzCode gewöhnt, werden diese Informationen direkt in einer Debugging-Session angezeigt und helfen somit, eine LINQ-Anweisung besser zu verstehen.

OzCode zeigt die Daten der aktuellen Debugging-Session direkt im Editor von Visual Studio an. Das gilt auch für Numeric Indicator. Sobald die Ausführung eine LINQ-Anweisung erreicht, zeigt ein kleiner Indikator neben jedem LINQ-Operator die Anzahl der Elemente an, die durch den Operator aus der Gesamtmenge ausgewählt worden sind. Dadurch ist ein schneller Überblick möglich, wie die LINQ-Anweisung die Menge an Elementen einschränkt. Ein Blick genügt also, um festzustellen, wo diese Einschränkungen nicht stimmen können und warum das LINQ-Statement somit nicht so funktioniert, wie das ursprünglich geplant war. Bild 1 zeigt einen Screenshot einer LINQ-Anweisung mit den angesprochenen Indikatoren auf der rechten Seite.

OzCode kann aber nicht nur Informationen direkt in den Editor einbetten. Einige Daten sind komplexerer Natur beziehungsweise erfordern mehr Interaktion mit einem Benutzer, so dass Extrafenster notwendig sind. So ein Fenster bringt auch LINQ DataTip auf den Schirm. Es erscheint, wenn ein Numeric Indicator angeklickt wird. Dadurch versetzen Sie OzCode in den LINQ-Debugging-Modus.

Bild 2 zeigt dieses Datenfenster an der gleichen LINQ-Abfrage, die schon in Bild 1 zu sehen war.

Angeklickt wurde der Indikator neben dem Select. Dieser LINQ-Operator hat 81 Elemente aus der Gesamtdatenmenge ausgewählt, die alle in der Liste im DataTip-Fenster rechts zu sehen sind. Das erlaubt es beim Debuggen sofort zu sehen, welche das sind. Zudem ermöglicht es OzCode, durch scrollen in der Liste oder durch drehen am Mausrad, durch diese Liste zu navigieren. Damit verändert sich nicht nur der Eintrag in der Liste ebendieses DataTip-Fensters, sondern alle zugehörigen und von OzCode angezeigten Informationen des LINQ-Statements.

Darüber hinaus gibt es noch das sogenannte LINQ Analysis Window. Bild 3 zeigt das Fenster für das bereits bekannte LINQ-Statement. Dieses Fenster zeigt die Daten der einzelnen Schritte auf Basis der LINQ-Operatoren. Ganz links außen ist die Quelldatenmenge zu sehen, benannt mit Source. Anschließend erfolgt das Select, dann Where, GroupBy, OrderBy und Last.

Alle Operatoren zeigen über die Zahl, wie viele Elemente durch die jeweiligen Operationen ausgewählt worden sind. Um das noch besser nachvollziehen zu können, zeigen die einzelnen Schritte die Daten des vorherigen (links) und des aktuellen (rechts) Operators an. Dadurch ist ersichtlich, welche Elemente es in die nächste Menge schaffen beziehungsweise welche durch die Operation ausgesiebt werden. Das verbessert das Verständnis der LINQ-Anweisung enorm, da die manuellen Debug-Ausgaben auf zum Bespiel der Konsole oder gar das Rätselraten entfallen, wie die LINQ-Anweisung die Daten verarbeitet.

Das LINQ Analysis Window bietet zudem OzCode-Funktionen wie Reveal und Search an. Auf diese Weise lassen sich Objekte beziehungsweise allgemein die Daten von Interesse schnell in den jeweiligen Ergebnismengen ausfindig machen.

Die genannten Funktionen spielen besonders dann eine große Rolle, wenn Exceptions in einer LINQ-Anweisung auftreten. OzCode bemerkt das, bevor die entsprechende Stelle ausgeführt wird. Zum Beispiel dann, wenn der letzte Eintrag in einer Datenmenge eine Exception auslösen würde. Bevor wir als Entwickler zu dieser Stelle springen können, färbt sich der Numeric Indicator rot und gibt damit bekannt, dass eine Exception bevorsteht. Auf diese Weise ist es beim Debuggen möglich, die Daten bis zu dieser Stelle zu untersuchen, um so dem Fehler deutlich schneller auf die Schliche zu kommen.

OzCode war bereits in Version 2.x eine große Hilfe beim Debuggen von C#-Code. In Version 3.0 wird das noch einmal getoppt. Dafür sorgen das LINQ-Debugging und die Integration in Visual Studio 2017 direkt vom Start weg. Die Visual-Studio-Erweiterung OzCode ist daher mehr denn je einen Blick wert. Weitere Informationen zu OzCode beinhalten die beiden Artikel Magische Fehlersuche [3] und Leichter debuggen [4].