Editor Options in SSMS — Make SQL Code Look the Same on Every Team Machine

A SQL statement that looks neatly indented on one developer’s machine collapses into a staircase on a colleague’s — even though nobody touched the code. The culprit is almost always a difference in editor settings: a different tab width, tabs instead of spaces, a non-monospaced font. Readable SQL code in a team doesn’t start with typing — it starts with the editor options.

The essentials up front:

• A monospaced font is the basis of any column-exact alignment — without it, characters won’t line up reliably beneath one another.
• Spaces instead of tabs make a statement’s indentation independent of the configured tab width — it looks the same in every editor.
• A consistent tab and indent width keeps the same statement from collapsing differently for two developers.
• Block indentation saves you a lot of typing when formatting by hand.
• Beyond SSMS, the same principles apply in VS Code, Azure Data Studio and others — best pinned down project-wide with an .editorconfig.

Prerequisite: an editor with configurable font and tab settings. SSMS serves as the example here; the principles apply to any SQL editor (Azure Data Studio, VS Code, DataGrip, DBeaver).

Contents

• Why uniform editor settings matter
• Monospaced font
• No mixing of spaces and tabs
• Replacing tabs with spaces
• Block indentation
• Beyond SSMS: the same settings in every editor
• Conclusion
• FAQ

Why uniform editor settings matter

Editors in the well-known development environments — SQL Server Management Studio (SSMS) included — use monospaced fonts: every character takes up the same width. That makes text easy to indent and align, for instance with the Tab key, which indents several characters at once. But this is exactly where the trouble starts:

• By how many characters is the text indented?
• Which character does the Tab key insert — a tab or spaces?
• What happens when developers use different editors?
• What happens when developers have set different tab widths?

So the prerequisite for structured code in a multi-developer environment is that everyone agrees on uniform editor settings — regardless of which editor they use. That pays off beyond looks: consistent indentation produces no whitespace-only diffs in version control, and code reviews can focus on the actual changes. Four settings matter here:

• Monospaced font
• No mixing of spaces and tabs
• Replacing tabs with spaces
• Block indentation

Monospaced font

Since virtually all integrated development environments use monospaced fonts in their editors by default, this point may seem obvious. It is mentioned here for completeness.

In a non-monospaced font, a character only takes up as much space as its representation requires. The letter i will always take less space than an m. This naturally causes problems when aligning text elements.

In the font Arial, the conditions of the WHERE clause on the fields [name] and [system_type_id] cannot be aligned flush left. In the monospaced font Consolas they can, as the example shows.

Column-exact alignment — and thus structured formatting of SQL code — is therefore only possible with monospaced fonts. Indentation as such works in a proportional font too, but the columns will not line up reliably there.

Configuration in SSMS

A note on the screenshots (as of 2026): The screenshots are from SSMS 2012. In SSMS 22.6 (built on the Visual Studio 2022 shell) the options live under the new “All Settings” interface. Of all things, Fonts and Colors has still not been migrated there — SSMS shows the note “These settings haven’t been migrated yet. Links will open in the legacy Options dialog.” and still opens the classic Options dialog. So the paths shown here still apply; only the navigation to them has gained an extra wrapper in newer versions.

The font can be set via the SSMS options: Options | Environment | Fonts and Colors

Monospaced fonts are shown in bold in the font list.

No mixing of spaces and tabs

Every developer has their own preferences for formatting SQL code. Some reach for the tab as their indentation tool of choice, others labour away with spaces — and most probably don’t think about it at all. When SQL procedures and the like are edited by several developers, tabs and spaces quickly get mixed. As long as the tab width is set to, say, 3 characters in every editor the developers use, a SQL statement may look consistently formatted. But once one developer uses a tab width of 3 and another a tab width of 4, a statement quickly becomes unreadable and ill-suited to efficient editing. The following statement illustrates this mix of spaces and tabs as a means of indentation:

At a tab width of four characters the pipe symbols are obviously aligned. With other tab widths, however, it quickly becomes clear that the alignment is lost.

In this example the differing indentations may seem minimal. With more complex statements, mixing tabs and spaces can quickly tear a SQL statement apart.

The reason for a mix of spaces and tabs need not only be different settings within SSMS — it can also be the use of different editors.

Configuration in SSMS

The indent size can be set via the SSMS options: Options | Text Editor | Transact-SQL | Tabs

Recommendation

• Always use spaces for indentation.
• Spaces allow far more precise formatting.
• With spaces, the statement’s indentation is identical regardless of the editor used.

Tip

• Box selection (called “column selection” in SSMS, “box selection” in VS Code and Azure Data Studio) lets you enter and indent several lines or text blocks at once.
• See also the article The Functional Aesthetics of SQL.

Replacing tabs with spaces

If the editor automatically replaces tabs with spaces, the indentation of SQL statements is preserved regardless of the editor chosen and the tab width set.

Strictly speaking, this is a convention, not a law of nature: pure tab indentation works too, as long as every single person involved has configured the same tab width. Spaces take that precondition out of the picture — the indentation then no longer depends on any tab setting.

Recommendation

• Always have tabs replaced with spaces. That keeps the formatting precise and a statement’s indentation identical regardless of the editor and its tab width.

Configuration in SSMS

Replacing tabs with spaces can be set via the SSMS options: Options | Text Editor | Transact-SQL | Tabs

Note

The indent size is to be distinguished from the tab width. The tab width only specifies how many characters a tab character occupies. Pressing the Tab key indents by the indent size. If, for example, the indent size is 10 and the tab width is 5, then pressing the Tab key inserts 2 tab characters, each with a tab width of 5 characters.

Block indentation

Granted, using spaces to structure SQL statements means extra effort. SSMS helps the developer here with the block-indentation option. What’s it all about?

If the cursor sits behind the character *, for example, and the developer presses the Enter key, not only is a new blank line inserted — the cursor is automatically aligned with the first character of the previous line. Without the block-indentation option, the cursor would always be placed at position 1 of the new line.

In fact, the spaces and/or tabs for this indentation are only inserted once the developer starts typing a character.

Recommendation

Use block indentation to align each new line with the previous one.

Configuration in SSMS

Block indentation can be set via the SSMS options: Options | Text Editor | Transact-SQL | Tabs

Beyond SSMS: the same settings in every editor

SSMS has long ceased to be the only editor for SQL. Anyone working with SQL Server or Postgres today often uses Azure Data Studio, VS Code (with the mssql or PostgreSQL extension), DataGrip or DBeaver. The good news: the three settings from this article — a monospaced font, replacing tabs with spaces, a consistent tab and indent width — exist in every one of these editors. Only the menu items are named differently.

Set it once for all: .editorconfig

Instead of redoing the settings in each editor individually, you can solve the core problem — “every developer has different settings” — at the root: with an .editorconfig file in the project repository. It defines indentation, tab behaviour and character encoding across editors. Visual Studio and JetBrains IDEs such as DataGrip read it natively; VS Code needs the free “EditorConfig for VS Code” extension for it. A minimal set for SQL files:

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

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

These four lines define, in every editor that supports .editorconfig: spaces instead of tabs, three characters of indentation, no trailing whitespace. These are exactly the recommendations from the sections above, only enforced automatically.

One catch, of all things, for SSMS: its T-SQL editor does not honour the generic .editorconfig properties such as indent_style and indent_size while you type. So for the typing behaviour you stay with the Tabs dialog from above. Since SSMS 22.7, however, there is a built-in SQL Formatter (Preview) (Ctrl+K, Ctrl+Q, optional format-on-save) that can likewise be configured through an .editorconfig. It uses its own keys for this, such as indentation_mode = Spaces and indentation_size = 3, instead of the generic properties. If you want to pin the formatting down in the repository, you maintain these formatter keys for SSMS as well.

Auto-formatters: layout at the push of a button

Tools like sqlfluff (for SQL in general) or pgFormatter (for Postgres) format a statement automatically according to defined rules. That saves typing and enforces a uniform style across the whole team. Since version 22.7, SSMS itself ships a built-in formatter as well (see above). One limitation remains, though: an auto-formatter enforces an agreed layout automatically. It doesn’t replace the understanding that comes from structuring a statement by hand. In the age of Copilot and Cursor especially, generated, neatly formatted SQL code that nobody reads any more is a risk in its own right (more on this in the article The Functional Aesthetics of SQL).

And in Postgres?

The principles are the same — only the tooling differs. In pgAdmin, DBeaver or psql you likewise set a monospaced font and space-based indentation. The common naming convention for Postgres is snake_case in lower case; an .editorconfig and pgFormatter apply here just as they do for SQL Server.

Conclusion

Four editor settings decide whether SQL code looks the same on every machine in a team: a monospaced font, no mixing of tabs and spaces, automatic replacement of tabs with spaces, and block indentation. All four are set in SSMS in a few minutes and take effect from the next statement on.

If you don’t want to leave the settings to each team member individually, pin them down with an .editorconfig in the project repository. The same indentation rule then applies automatically in VS Code, DataGrip and the other editors. Only the T-SQL editor in SSMS remains a special case: while typing, the Options dialog still rules — only the SQL Formatter (Preview) as of SSMS 22.7 reads an .editorconfig, with its own keys.

FAQ