Überblick
Vor einiger Zeit habe ich eine äußerst umfangreiche Prozedur mit bald 2.000 Zeilen Code überarbeitet. Die Prozedur wurde nacheinander von drei Entwicklern bearbeitet. Sie enthielt zu ca. 30 Tabellen/Entitäten unterschiedlich umfangreiche Statements, die jedoch im Wesentlichen alle die gleiche Aufgabe hatten. Die SQL Statements je Tabelle/Entität hätten demnach alle ähnlich ausschauen können. Tatsächlich gab es Abweichungen von Entwickler zu Entwickler und auch Abweichungen innerhalb der Arbeit eines Entwicklers, die mal weniger, mal größere Auswirkungen auf die Lesbarkeit und Wartbarkeit der Prozedur hatten:
- Wurden Begrenzungsbezeichner (Delimiter) verwendet?
- Wie sieht es mit Groß-/Kleinschreibung von Schlüsselwörtern, Funktionsnamen, etc. aus?
- Wurden bei Entitäts-/Tabellen-Wechseln Inline-Kommentare eingefügt?
- Sind eher temporäre Tabellen oder Tabellen-Variablen zu verwenden?
- …
In den vergangenen 20 Jahren meiner Tätigkeit als Consultant sind viele Versuche, Regeln für die Formatierung und Strukturierung von Quellcode gescheitert oder von kontroversen Diskussionen begleitet worden. Da hat jemand im Laufe seines Entwicklerlebens seine Präferenzen entwickelt und nun soll man neue Vorgaben akzeptieren und anwenden? Der Mensch ist ein Gewohnheitstier scheint damit häufig überfordert.
Bei dem Review einer anderen Prozedur, die von einem Kollegen geschätzten geschrieben wurde, hatte mir die verwendete Strukturierung und Formatierung der Statements so gar nicht zugesagt. Ohne mir Gedanken über die Folgen zu machen, hatte ich Prozedur während des Reviews mal geschwind umformatiert. Inhaltlich war sie korrekt und fehlerfrei. Durch den Eincheck-Vorgang wurde die Prozedur als geändert markiert. Auf Grund meiner umfangreichen Überarbeitung war am Ende nicht mehr zu erkennen, ob die Prozedur inhaltlich geändert wurde.
Kritik habe ich mir anhören müssen, zu Recht.
Da das SQL Server Management Studio nur mäßig bis gar nicht bei der Formatierung von Statements unterstützt, sind Entwickler in einem Mehrentwickler-Projekt besonders gefordert, einheitliche Standards zu definieren und anzuwenden, um optimale Lesbarkeit und Wartbarkeit zu erreichen.
Mit dieser Artikel Serie möchte ich Best Practices bezüglich Strukturierung und Formatierung zusammentragen:
- Editor Optionen in SSMS
- Formatierung von SQL Statements (Teil 1)
- Formatierung von SQL Statements (Teil 2)
- Kommentierung eines komplexen SQL Statements
- Strukturierung von Prozeduren, Funktionen, etc.
- Kommentierung von Prozeduren, Funktionen, etc.