Mittendrin.

Zurück

Flurfunk der eXperts.

Hier erfahren Sie mehr über eXperts, Technologien und das wahre Leben in der SDX.

LINQ Coding Guidelines–WrapUp

22.06.201508:00 Uhr , Alexander Jung

Im ersten Beitrag dieser Serie habe ich das Fehlen von Coding Guidelines für LINQ beklagt. Während wir bei bei “normalem” Code auf Diskussionen in der Vergangenheit und diverse Guidelines zurückgreifen können – von Namenskonventionen bis hin zur Frage, ob die geschweifte Klammer in eine eigene Zeile gehört – scheint es hierzu bei LINQ nicht einmal eine Auseinandersetzung zu geben.

 

Mit meinen Beiträgen habe ich versucht, zunächst die Notwendigkeit zu beschreiben (”Error not found”) und einige Klarstellungen vorwegzuschicken (Definition). Die konkreten Guidelines sind nicht das Ergebnis theoretischer Überlegungen, sondern basieren auf realen Beispielen und Erfahrungen. Hier ist der vollständige Überblick:

  1. Null-Werte für Enumerationen
  2. Kein Mischen der Syntax
  3. Einrückungen und Umbrüche
  4. Mapping von Daten separieren
  5. Komplexe Lambda-Funktionen auslagern
  6. Behandlung von optionalen Filterkriterien
  7. Listen nicht von Hand befüllen
  8. Provider nicht mischen
  9. Die richtigen Methoden verwenden
  10. Methoden richtig verwenden
  11. Der Einsatz von “var”
  12. Anonyme Klassen
  13. Die Verwendung von Generics als Datentypen

Natürlich sind einige der Regeln relevanter, als andere. Und gelegentlich geht Lesbarkeit mit Kompromissen einher, etwa wenn die Verwendung eines Mappers (#4) oder vordefinierte Datentypen (#12) verhindern, dass eine komplexe Abfrage Daten aus mehreren Tabellen mit genau den benötigten Feldern zusammenführen kann.

In solchen Fällen ist Augenmaß gefragt. Guidelines sind Hilfen für die üblichen Fälle, sie haben keinen Anspruch auf Universalität und Unfehlbarkeit. Anders ausgedrückt: In Ausnahmefällen davon abzuweichen – und diese Ausnahme über einen Kommentar zu dokumentieren – ist völlig in Ordnung. Andererseits kann man solche Fälle aber auch als Denkanstoß nehmen und sich überlegen, ob eine komplexe Abfrage nicht besser in einer View oder Stored Procedure in die Datenbank aufgehoben wäre.

Damit schließe ich diese Serie ab. Falls jemand Anmerkungen (Widersprüche?) oder Ergänzungen hat, kann er mir die gerne mitteilen. Für eine gute Diskussion bin ich immer zu haben… 😉

Tags: .NET Dev LINQ

0 Kommentare
Dein Kommentar wartet auf Freischaltung.

Artikel kommentieren

Zurück

Tag Cloud


Kontakt aufnehmen


Anrufen

Gerne beantworten wir Ihre Fragen in einem persönlichen Gespräch!


Kontakt aufnehmen

Schreiben Sie uns eine E-Mail mit Ihren Fragen und Kommentaren!