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

Veröffentlicht 27.05.2018 · Aktualisiert 26.08.2026
von

 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 spaltengenauen Ausrichtung — ohne sie fluchten Zeichen nicht zuverlässig untereinander.
  • Leerzeichen statt Tabulatoren machen die Einrückung eines Statements unabhängig von der eingestellten Tab-Weite — sie sieht in jedem Editor gleich aus.
  • Einheitliche Tab- und Einrückungsweite verhindert, dass dasselbe Statement bei zwei Entwicklern unterschiedlich zerfällt.
  • Blockweise Einrückung nimmt 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).

Inhalt

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. Das zahlt sich über die Optik hinaus aus: Einheitliche Einrückung erzeugt keine reinen Whitespace-Diffs in der Versionsverwaltung, und Code-Reviews können sich auf die inhaltlichen Änderungen konzentrieren. 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 ihren Editoren verwenden, erscheint dieser Punkt selbstverständlich. Der Vollständigkeit halber gehört er trotzdem an den Anfang.

In einer monospaced Schrift beansprucht jedes Zeichen dieselbe Breite, sodass untereinander stehende Zeichen exakt fluchten.

Bei nicht-monospaced Schriften beansprucht ein Zeichen genau so viel Platz, wie für seine Darstellung erforderlich ist. Ein i beansprucht immer weniger Platz als ein m. Daraus ergeben sich Probleme bei der Ausrichtung von Text-Elementen.

Dasselbe WHERE-Statement in Arial und in Consolas: In der Proportionalschrift Arial fluchten die Felder [name] und [system_type_id] nicht, in der monospaced Consolas stehen sie linksbündig untereinander.

In der Schriftart Arial lassen sich die Bedingungen der WHERE-Klausel auf den Feldern [name] und [system_type_id] nicht linksbündig ausrichten. In der monospaced Schriftart Consolas gelingt genau das, wie das Beispiel zeigt.

Die spaltengenaue Ausrichtung und damit eine strukturierte Formatierung von SQL-Code sind daher nur mit monospaced Schriftarten möglich. Einrücken lässt sich zwar auch in einer Proportionalschrift, verlässlich fluchten die Spalten dort aber nicht.

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

SSMS-Optionsdialog unter Umgebung, Schriftarten und Farben, in dem die Editor-Schriftart eingestellt wird.

Monospaced Schriftarten sind in der Liste der Schriftarten fett dargestellt.

Schriftarten-Auswahlliste in SSMS: monospaced Schriftarten sind fett hervorgehoben.

Keine Vermischung von Leerzeichen und Tabulatoren

Jeder Entwickler hat eigene Vorlieben bei der Formatierung von SQL-Code. Die einen rücken mit dem Tabulator ein, die anderen tippen Leerzeichen, um SQL-Code zu formatieren. Bearbeiten mehrere Entwickler dieselben SQL-Prozeduren, vermischen sich beide Varianten schnell. Solange die Tab-Weite in allen verwendeten Editoren auf denselben Wert festgelegt ist, zum Beispiel 3 Zeichen, bleibt ein SQL-Statement stimmig formatiert. Verwendet aber ein Entwickler die Tab-Weite 3 und ein anderer die Tab-Weite 4, wird ein Statement schnell unleserlich und lässt sich kaum noch effizient bearbeiten. Das nachfolgende Statement zeigt die Vermischung von Leerzeichen und Tabulatoren als Mittel der Einrückung:

Ein mit gemischten Tabulatoren und Leerzeichen eingerücktes Statement: Bei Tab-Weite 4 stehen die Pipe-Symbole sauber untereinander.

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.

Dasselbe Statement bei abweichender Tab-Weite: Die Pipe-Symbole fluchten nicht mehr, die Ausrichtung ist verloren.

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

SSMS-Optionsdialog unter Text-Editor, Transact-SQL, Tabstopps, in dem Tab-Weite und Einrückungsgröße eingestellt werden.

Empfehlung

  • Einrückungen stets mit Leerzeichen setzen.
  • Mit Leerzeichen ist eine wesentlich präzisere Formatierung möglich.
  • Leerzeichen gewährleisten unabhängig vom verwendeten Editor eine identische Darstellung des Statements.

Tipp

  • Die Blockauswahl (in SSMS „Spaltenauswahl“, in VS Code und Azure Data Studio „Box Selection“) unterstützt 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, bleibt die Einrückung von SQL-Statements unabhängig von der Wahl des Editors und der eingestellten Tab-Weite erhalten.

Streng genommen ist das eine Konvention, kein Naturgesetz: Auch eine reine Tabulator-Einrückung funktioniert, solange wirklich alle Beteiligten dieselbe Tab-Weite eingestellt haben. Leerzeichen nehmen diese Voraussetzung aus dem Spiel, denn die Einrückung hängt dann an keiner Tab-Einstellung mehr.

Ein Statement, bei dem Tabulatoren automatisch durch Leerzeichen ersetzt wurden — die Ausrichtung bleibt unabhängig von der Tab-Weite erhalten.

Empfehlung

  • Tabulatoren immer durch Leerzeichen ersetzen lassen. So bleibt die Formatierung präzise und die Einrückung eines Statements unabhängig vom verwendeten Editor und dessen Tab-Weite identisch.

Konfiguration in SSMS

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

SSMS-Optionsdialog Tabstopps mit aktivierter Option „Einfügen von Leerzeichen", die Tabulatoren durch Leerzeichen ersetzt.

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?

Blockweise Einrückung in SSMS: Nach Enter springt der Cursor automatisch unter das erste Zeichen der vorigen Zeile statt an den Zeilenanfang.

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 stünde der Cursor immer auf Position 1 der neuen Zeile.

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

  • Die blockweise Einrückung aktivieren: Sie richtet nachfolgende neue Zeilen automatisch an der jeweils vorangegangenen Zeile aus.

Konfiguration in SSMS

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

SSMS-Optionsdialog Tabstopps mit der Einrückungsoption „Block", die die blockweise Einrückung aktiviert.

Ü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

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. Das sind genau die Empfehlungen aus den Abschnitten oben, nur automatisch durchgesetzt.

Ein Wermutstropfen ausgerechnet für SSMS: Der T-SQL-Editor wertet die generischen .editorconfig-Eigenschaften wie indent_style und indent_size beim Tippen nicht aus. Wer in SSMS arbeitet, bleibt für das Tipp-Verhalten also beim Tabstopps-Dialog von oben. Seit SSMS 22.7 gibt es allerdings einen eingebauten SQL Formatter (Preview) (Ctrl+K, Ctrl+Q, optional Format-on-Save), der sich ebenfalls über eine .editorconfig konfigurieren lässt. Er verwendet dafür eigene Schlüssel wie indentation_mode = Spaces und indentation_size = 3 statt der generischen Eigenschaften. Wer die Formatierung im Repo festschreiben will, pflegt für SSMS also zusätzlich diese Formatter-Schlüssel.

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. Seit Version 22.7 bringt auch SSMS selbst einen eingebauten Formatter mit (siehe oben). Eine Einschränkung bleibt aber: Ein Auto-Formatter setzt eine vereinbarte Darstellung automatisiert durch. Das Verständnis, das beim manuellen Strukturieren eines Statements entsteht, ersetzt er nicht. 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 lassen sich monospaced Schrift und Leerzeichen-Einrückung ebenfalls einstellen. Die übliche Namens-Konvention für Postgres ist snake_case in Kleinschreibung. Eine .editorconfig und pgFormatter greifen hier genauso wie bei SQL Server.

Fazit

Vier Editor-Einstellungen entscheiden darüber, ob SQL-Code im Team überall gleich aussieht: eine monospaced Schriftart, der Verzicht auf gemischte Tabulatoren und Leerzeichen, das automatische Ersetzen von Tabulatoren durch Leerzeichen und die blockweise Einrückung. Alle vier sind in SSMS in wenigen Minuten gesetzt und wirken ab dem nächsten Statement.

Wer die Einstellungen nicht jedem Team-Mitglied einzeln überlassen will, schreibt sie mit einer .editorconfig im Projekt-Repository fest. Dieselbe Einrückungs-Regel gilt damit automatisch in VS Code, DataGrip und den übrigen Editoren. Nur der T-SQL-Editor von SSMS bleibt ein Sonderfall: Beim Tippen gilt weiterhin der Optionen-Dialog, erst der SQL Formatter (Preview) ab SSMS 22.7 liest eine .editorconfig mit eigenen Schlüsseln.

FAQ

Tabs oder Leerzeichen — was ist besser für SQL-Code?

Leerzeichen. Eine Einrückung aus Leerzeichen sieht in jedem Editor und bei jeder Tab-Weite identisch aus, während Tabulatoren je nach Einstellung unterschiedlich breit dargestellt werden. Sobald mehrere Entwickler an denselben Prozeduren arbeiten, ist das der entscheidende Unterschied zwischen lesbarem und zerfallendem Code. Am bequemsten ist es, den Editor Tabulatoren automatisch durch Leerzeichen ersetzen zu lassen.

Wie stelle ich die Tab-Weite in SSMS ein?

Über Optionen | Text-Editor | Transact-SQL | Tabstopps. Dort lassen sich Tab-Weite und Einrückungsgröße festlegen und die Option „Einfügen von Leerzeichen“ aktivieren, damit Tabulatoren automatisch ersetzt werden. Die Tab-Weite gibt an, wie breit ein Tabulator-Zeichen dargestellt wird. Die Einrückungsgröße bestimmt, um wie viele Zeichen die Tab-Taste einrückt.

Wie aktiviere ich eine monospaced Schriftart in SSMS?

Über Optionen | Umgebung | Schriftarten und Farben. In der Schriftarten-Liste sind monospaced Schriftarten (etwa Consolas) fett hervorgehoben. Nur mit ihnen lässt sich SQL-Code spaltengenau ausrichten, weil jedes Zeichen die gleiche Breite hat.

Gelten diese Einstellungen auch in VS Code, Azure Data Studio oder DataGrip?

Ja. Monospaced Schrift, Tabs-durch-Leerzeichen und eine einheitliche Tab-Weite gibt es in jedem ernstzunehmenden SQL-Editor, nur unter anderen Menüpunkten. Wer die Einstellungen teamweit und editor-übergreifend festschreiben will, legt eine .editorconfig ins Projekt-Repository: Visual Studio und DataGrip lesen sie nativ, VS Code mit der Erweiterung „EditorConfig for VS Code“. Eine Teil-Ausnahme bleibt der T-SQL-Editor von SSMS: Beim Tippen wertet er .editorconfig nicht aus, dort führt der Tabstopps-Dialog zum Ziel. Der seit SSMS 22.7 eingebaute SQL Formatter (Preview) liest eine .editorconfig dagegen, allerdings mit eigenen Schlüsseln wie indentation_size.