Introduction

If Visual Studio keeps moving your opening brace onto a new line, the IDE is following its active formatting rules. The fix is to change the brace and newline settings for the language you are editing, and if the project uses .editorconfig, make sure the repository rules do not override your local preference.

Change the Built-In C# Formatting Settings

For C#, the most direct path is through the formatting options dialog. In Visual Studio, go to Tools -> Options -> Text Editor -> C# -> Code Style -> Formatting -> New Lines.

In that page, clear the options that say things like:

• place open brace on new line for types
• place open brace on new line for methods
• place open brace on new line for control blocks

Once those are unchecked, formatting commands should stop converting this:

1if (ready)
2{
3    Run();
4}

into the all-newline style, and will instead preserve or produce:

if (ready) {
    Run();
}

The exact wording may vary a little between Visual Studio versions, but the relevant category is the newline formatting section for the active language.

Check Whether .editorconfig Is Overriding the IDE

Many teams keep formatting rules in .editorconfig. If that file exists in the repository, Visual Studio may apply its rules even after you change the IDE settings.

A minimal example for brace placement looks like this:

[*.cs]
csharp_new_line_before_open_brace = none

If the project contains a conflicting rule, your local options may appear to "do nothing" because the repo-level style wins. In that case, the real fix is to update .editorconfig or agree on the formatting rule with the team.

This is usually the first thing to check when one machine formats code differently from another.

Reformat a File After Changing the Rule

After adjusting the settings, reformat the document to confirm the rule is actually applied.

Edit -> Advanced -> Format Document

or use the keyboard shortcut assigned to format the file in your Visual Studio setup. If the code still moves to the next line, one of three things is usually true:

• the wrong language settings were changed
• '.editorconfig is overriding them'
• a third-party extension is formatting the file afterward

Testing with a tiny file makes this easy to isolate.

Extensions and Alternate Formatters

Some developers use ReSharper, Rider-style settings, or other formatting extensions. Those tools can impose their own brace rules and ignore the plain Visual Studio configuration.

If you have one installed, look for the equivalent brace-placement setting there or temporarily disable the extension and format again. Otherwise you can spend time changing the correct Visual Studio option while another formatter immediately undoes it.

Keep Project Style in Mind

You can absolutely prefer same-line braces, but if the repository uses allman-style formatting, changing local settings alone may create noisy diffs every time you save a file. The pragmatic solution is to decide whether you are changing personal formatting for an isolated project or updating the shared style for the entire codebase.

That distinction matters more than the specific brace preference. Consistency usually matters more than which style wins.

Common Pitfalls

• Changing the Visual Basic or C++ formatting page instead of the C# formatting page has no effect on C# files.
• Forgetting about .editorconfig leads to confusion because repository settings can override the IDE options silently.
• Reformatting with an extension such as ReSharper can reintroduce newline braces even after Visual Studio settings were changed correctly.
• Testing with an existing file that already has mixed formatting can hide whether the setting really changed. Use a tiny fresh example first.
• Applying a local style that conflicts with the team repository rules can create unnecessary formatting churn in commits.

Summary

• Visual Studio puts braces on a new line because of active formatting rules, not because the behavior is fixed.
• For C#, change the newline brace settings under the language formatting options.
• If the project uses .editorconfig, update that file when repository rules override local preferences.
• Reformat a small test snippet to confirm the new rule is actually active.
• Check third-party formatters if Visual Studio keeps undoing the change.