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… 😉