Editor-Optionen in SSMS — damit SQL-Code im Team überall gleich aussieht

 Ein SQL-Statement, das beim einen Entwickler sauber eingerückt aussieht, zerfällt beim Kollegen in ein Treppenmuster — obwohl niemand etwas am Code geändert hat. Schuld sind fast immer unterschiedliche Editor-Einstellungen: eine andere Tab-Weite, Tabulatoren statt Leerzeichen, eine nicht-monospaced Schriftart. Lesbarer SQL-Code im Team beginnt deshalb nicht beim Tippen, sondern bei den Editor-Optionen.

Das Wichtigste vorab:

• Monospaced Schriftart ist die Grundlage jeder Ausrichtung — ohne sie lässt sich nichts sauber einrücken.
• Leerzeichen statt Tabulatoren sorgen dafür, dass ein Statement in jedem Editor identisch aussieht.
• Einheitliche Tab- und Einrückungsweite verhindert, dass dasselbe Statement bei zwei Entwicklern unterschiedlich zerfällt.
• Blockweise Einrückung nimmt dir beim Formatieren von Hand viel Tipparbeit ab.
• Über SSMS hinaus gelten dieselben Prinzipien in VS Code, Azure Data Studio & Co. — am besten projektweit per .editorconfig festgeschrieben.

Voraussetzung: ein Editor mit konfigurierbaren Schrift- und Tab-Einstellungen. SSMS dient hier als Beispiel; die Prinzipien gelten für jeden SQL-Editor (Azure Data Studio, VS Code, DataGrip, DBeaver).

Warum einheitliche Editor-Einstellungen

Editoren der bekannten Entwicklungsumgebungen — SQL Server Management Studio (SSMS) eingeschlossen — verwenden monospaced Schriften: Jedes Zeichen beansprucht die gleiche Breite. Damit lässt sich Text hervorragend einrücken und ausrichten, etwa über die Tab-Taste, die gleich mehrere Zeichen weit einrückt. Doch genau hier fangen die Probleme an:

• Um wie viele Zeichen wird der Text eingerückt?
• Welches Zeichen fügt die Tab-Taste ein — einen Tabulator oder Leerzeichen?
• Was passiert, wenn Entwickler unterschiedliche Editoren verwenden?
• Was passiert, wenn Entwickler unterschiedliche Tab-Weiten eingestellt haben?

Voraussetzung für strukturierten Code in einer Mehrentwicklerumgebung ist daher, dass sich alle Entwickler auf einheitliche Editor-Einstellungen einigen — unabhängig davon, welcher Editor verwendet wird. Vier Einstellungen sind dafür relevant:

• Monospaced Schriftart
• Keine Vermischung von Leerzeichen und Tabulatoren
• Tabulatoren durch Leerzeichen ersetzen
• Blockweise Einrückung

Monospaced Schriftart

Da wohl alle integrierten Entwicklungsumgebungen per Default monospaced Schriftarten in den Editoren verwenden, erscheint dieser Punkt als selbstverständlich. Der Vollständigkeit halber soll dieser hier erwähnt werden.

Bei Non-Monospaced Schriften beansprucht ein Zeichen genau so viel Platz wie für seine Repräsentation erforderlich ist. Ein i wird immer weniger Platz als ein m beanspruchen. Hieraus ergeben sich natürlich Probleme bei der Ausrichtung von Text-Elementen.

Die Bedingungen der WHERE-Klausel auf den Feldern [name] und [system_type_id] können bei Verwendung der Schriftart Arial nicht wie in dem nachfolgenden Beispiel bei Verwendung der Schriftart Consolas linksbündig exakt ausgerichtet werden.

Einrückungen und damit eine strukturierte Formatierung von SQL-Code sind daher nur bei Verwendung von monospaced Schriftarten möglich.

Konfiguration in SSMS

Hinweis zu den Screenshots (Stand 2026): Die Screenshots stammen aus SSMS 2012. In SSMS 22.6 (auf Visual-Studio-2022-Unterbau) liegen die Optionen unter der neuen „All Settings“-Oberfläche. Ausgerechnet Fonts and Colors ist dort bis heute nicht migriert — SSMS blendet den Hinweis „These settings haven’t been migrated yet. Links will open in the legacy Options dialog.“ ein und öffnet weiter den klassischen Optionen-Dialog. Die gezeigten Pfade gelten also unverändert; nur die Navigation dorthin hat in neueren Versionen einen zusätzlichen Wrapper bekommen.

Die Schriftart kann über die Optionen des SSMS eingestellt werden: Optionen | Umgebung | Schriftarten und Farben

Monospaced Schriftarten sind in der Liste der Schriftarten fett dargestellt.

Keine Vermischung von Leerzeichen und Tabulatoren

Jeder Entwickler hat so seine Vorlieben hinsichtlich der Formatierung von SQL-Code. Die einen verwenden eher den Tabulator als Mittel der Wahl für die Einrückung und die anderen mühen sich mit der Eingabe von Leerzeichen ab um SQL-Code zu formatieren. Werden SQL-Prozeduren etc. von mehreren Entwicklern bearbeitet, werden schnell Tabulatoren und Leerzeichen vermischt. Solange die Tab-Weite in allen von den Entwicklern verwendeten Editoren überall auf zum Beispiel 3 Zeichen festgelegt ist, mag ein SQL-Statement stimmig formatiert sein. Verwendet jedoch ein Entwickler die Tab-Weite 3 und ein anderer die Tab-Weite 4, wird ein Statement schnell unleserlich und ist für eine effiziente Bearbeitung eher ungeeignet. Das nachfolgende Statement verdeutlicht die Vermischung von Leerzeichen und Tabulatoren als Mittel für die Einrückung:

Augenscheinlich sind die Pipe-Symbole bei einer Tab-Weite von vier Zeichen ausgerichtet. Bei Verwendung anderer Tab-Weiten wird jedoch schnell deutlich, dass die Ausrichtung verloren geht.

In diesem Beispiel mögen die abweichenden Einrückungen nur minimal erscheinen. Bei komplexeren Statements kann die Durchmischung von Tabulatoren und Leerzeichen ein SQL-Statement schnell zerrupfen.

Grund für die Durchmischung von Leerzeichen und Tabulatoren können nicht nur unterschiedliche Einstellungen in SSMS sein, sondern auch die Verwendung von unterschiedlichen Editoren.

Konfiguration in SSMS

Die Größe der Einrückung kann über die Optionen des SSMS eingestellt werden: Optionen | Text-Editor | Transact-SQL | Tabstopps

Empfehlung

• Verwende stets Leerzeichen für Einrückungen.
• Mit der Verwendung von Leerzeichen ist eine wesentlich präzisere Formatierung möglich.
• Bei Verwendung von Leerzeichen ist unabhängig von dem verwendeten Editor eine identische Darstellung des Statements gewährleistet.

Tipp

• Die Blockauswahl (in SSMS „Spaltenauswahl“, in VS Code und Azure Data Studio „Box Selection“) unterstützt dich bei der Eingabe und Einrückung gleich mehrerer Zeilen oder Text-Blöcke auf einmal.
• Siehe auch den Artikel Die funktionale Ästhetik von SQL.

Tabulatoren durch Leerzeichen ersetzen

Sofern Tabulatoren von dem verwendeten Editor automatisch durch Leerzeichen ersetzt werden, werden SQL-Statements unabhängig von der Wahl des Editors und der eingestellten Tab-Weite immer korrekt dargestellt.

Empfehlung

• Ersetze Tabulatoren immer durch Leerzeichen. Nur so ist eine präzise Formatierung von SQL-Code möglich und sichergestellt, dass die Repräsentation eines Statements unabhängig von dem verwendeten Editor immer korrekt ist.

Konfiguration in SSMS

Die Ersetzung von Tabulatoren durch Leerzeichen kann über die Optionen des SSMS eingestellt werden: Optionen | Text-Editor | Transact-SQL | Tabstopps

Anmerkung

Die Größe der Einrückung ist von der Tab-Weite zu unterscheiden. Die Tab-Weite gibt lediglich an, wie viele Zeichen ein Tabulator-Zeichen beansprucht. Beim Drücken der Tab-Taste erfolgt eine Einrückung um die Einrückungsweite. Beträgt die Einrückungsweite zum Beispiel 10 und die Tab-Weite 5, dann werden beim Drücken der Tab-Taste 2 Tab-Zeichen mit je einer Tab-Weite von 5 Zeichen eingefügt.

Blockweise Einrückung

Sicherlich bedeutet die Verwendung von Leerzeichen als Mittel für die strukturierte Formatierung von SQL-Statements einen Mehraufwand. SSMS unterstützt den Entwickler hier mit der Option der blockweisen Einrückung. Was hat es damit auf sich?

Befindet sich der Cursor zum Beispiel hinter dem Zeichen * und drückt der Entwickler die Enter-Taste, wird nicht nur eine neue leere Zeile eingefügt, sondern der Cursor wird automatisch an dem ersten Zeichen der vorangegangenen Zeile ausgerichtet. Ohne die Option der blockweisen Einrückung würde der Cursor immer auf die Position 1 der neuen Zeile positioniert werden.

Tatsächlich werden die Leerzeichen und/oder Tabulatoren für diese Einrückung erst dann eingefügt, wenn der Entwickler mit der Eingabe eines Zeichens beginnt.

Empfehlung

Verwende die blockweise Einrückung, um nachfolgende neue Zeilen an der jeweils vorangegangenen Zeile auszurichten.

Konfiguration in SSMS

Die blockweise Einrückung kann über die Optionen des SSMS eingestellt werden: Optionen | Text-Editor | Transact-SQL | Tabstopps

Über SSMS hinaus: dieselben Einstellungen in jedem Editor

SSMS ist längst nicht mehr der einzige Editor für SQL. Wer heute mit SQL Server oder Postgres arbeitet, nutzt oft Azure Data Studio, VS Code (mit der mssql- oder PostgreSQL-Erweiterung), DataGrip oder DBeaver. Die gute Nachricht: Die drei Stellschrauben aus diesem Artikel — monospaced Schriftart, Tabulatoren durch Leerzeichen ersetzen, einheitliche Tab- und Einrückungsweite — gibt es in jedem dieser Editoren. Nur die Menüpunkte heißen anders.

Einmal festlegen für alle: .editorconfig

Statt die Einstellungen in jedem Editor einzeln nachzuziehen, lässt sich das Kernproblem — „jeder Entwickler hat andere Einstellungen“ — an der Wurzel lösen: mit einer .editorconfig-Datei im Projekt-Repository. Sie legt Einrückung, Tab-Verhalten und Zeichenkodierung editor-übergreifend fest. Visual Studio und JetBrains-IDEs wie DataGrip lesen sie nativ; VS Code braucht dafür die kostenlose Erweiterung „EditorConfig for VS Code“. Ein minimaler Satz für SQL-Dateien:

[*.sql]
indent_style = space
indent_size = 3
trim_trailing_whitespace = true

[*.sql]
indent_style = space
indent_size = 3
trim_trailing_whitespace = true

Mit diesen vier Zeilen ist in jedem Editor, der .editorconfig unterstützt, festgelegt: Leerzeichen statt Tabulatoren, drei Zeichen Einrückung, keine überflüssigen Leerzeichen am Zeilenende — genau die Empfehlungen aus den Abschnitten oben, nur eben automatisch.

Ein Wermutstropfen ausgerechnet für SSMS: Der T-SQL-Editor wertet .editorconfig bis heute nicht aus. Wer in SSMS arbeitet, bleibt also beim Tabstopps-Dialog von oben — die .editorconfig greift dort (noch) nicht, wohl aber in VS Code, DataGrip & Co.

Auto-Formatter: Layout auf Knopfdruck

Tools wie sqlfluff (für SQL allgemein) oder pgFormatter (für Postgres) formatieren ein Statement automatisch nach festgelegten Regeln. Das nimmt Tipparbeit ab und erzwingt einen einheitlichen Stil im ganzen Team. Eine Einschränkung bleibt aber: Ein Auto-Formatter erzeugt nur Layout — er ersetzt nicht das Verständnis, das beim manuellen Strukturieren eines Statements entsteht. Gerade im Zeitalter von Copilot und Cursor ist generierter, hübsch formatierter SQL-Code, den niemand mehr liest, ein eigenes Risiko (mehr dazu im Artikel Die funktionale Ästhetik von SQL).

Und in Postgres?

Die Prinzipien sind dieselben — nur das Tooling unterscheidet sich. In pgAdmin, DBeaver oder psql stellst du ebenfalls monospaced Schrift und Leerzeichen-Einrückung ein. Die übliche Formatierungs-Konvention für Postgres ist snake_case in Kleinschreibung; eine .editorconfig und pgFormatter greifen hier genauso wie bei SQL Server.

FAQ