Cleaner code with C# 10 file-scoped namespaces

C# 10 introduced a small change that reshapes how .NET developers structure source files. File-scoped namespaces let a single declaration at the top of a file apply to every type defined below, removing the nested braces that have wrapped C# code for two decades. For teams across Sydney, Melbourne, and Brisbane maintaining sprawling enterprise solutions, the new style trims vertical noise and makes diffs easier to read during code review.

The change arrived alongside other quality of life improvements in .NET 6, including global usings, top level statements, and record structs. Together these features lean toward a lighter, more modern C# that feels closer to scripting languages while keeping the static type safety developers rely on. For Australian teams shipping solutions for the local banking, mining, and agriculture sectors, where maintainability over many years is essential, the new namespace style is a small ergonomic upgrade that compounds across an entire codebase.

Indentation also flattens. A class that previously sat four or five tabs deep now sits at the file root, which makes screen sharing during pair programming sessions less painful. Reviewers can focus on logic rather than bracket matching. For remote teams working across AEST and AEDT time zones, every saved keystroke matters.

Adoption is optional. The classic block scoped namespace still compiles fine, so projects can migrate at their own pace. Understanding when and why to make the change is more valuable than flipping a switch across every repository on the first day.

Why file-scoped namespaces matter

C# code is verbose by tradition. Every type lives inside one or more namespace blocks, and every block adds an extra indent. A typical service file might contain a namespace, a using directive region, and a class with curly braces stacking three or four deep. Multiply that across thousands of files in a solution and the result is thousands of lines of pure indentation that carry no information.

File-scoped namespaces answer a simple question: does the indentation of a block carry meaning if every type in the file belongs to the same namespace? The answer from the C# language design team was no. A single namespace MyApp.Services; declaration at the top of the file conveys the same information without the nesting.

The benefit shows up most clearly in generated code. Source generators produce thousands of partial files, each wrapped in identical namespace declarations. With file-scoped namespaces those files become shorter and faster to read when debugging. Teams near Atlassian's Sydney headquarters benefit directly.

The basic syntax at a glance

The new syntax replaces the opening brace with a semicolon. A file that previously looked like:

namespace MyApp.Services
{
    public class OrderProcessor
    {
    }
}

becomes:

namespace MyApp.Services;

public class OrderProcessor
{
}

Only one namespace declaration is allowed per file, and it must appear before any type declarations. Comments and using directives can sit above it. The compiler enforces these rules, so malformed files fail to build with a clear diagnostic rather than producing surprising behaviour.

Visual Studio 2022 and JetBrains Rider honour the new style automatically. Refactor menus, file templates, and new class dialogs all generate file-scoped namespaces by default in recent versions. Shops in Perth or Adelaide running older toolchains need an editor upgrade first.

Refactoring existing code to the new style

The fastest way to migrate a single file is to place the cursor on the namespace declaration, trigger the Quick Actions menu in Visual Studio, and choose "Convert to file-scoped namespace". The IDE removes the braces and reindents the body in one step. Rider offers an equivalent inspection with a keyboard shortcut.

For larger migrations, the Roslyn analyser IDE0230 and IDE0231 flag files that still use block scoped namespaces. Setting these to warning or error level in the editorconfig provides a steady reminder during code review. Australian consultancies can wire the rule into their shared editorconfig repositories and roll the change out across every active engagement at once.

A mechanical rewrite tool is also available. The .NET team published a script using the Roslyn syntax APIs that walks a project, converts each file, and writes the result back. For solutions with tens of thousands of files this approach is faster than touching each file by hand, though a careful review of the diff is still wise.

Combining file-scoped namespaces with global usings

File-scoped namespaces pair naturally with global usings, another C# 10 feature. A global using directive lives in a single file, often named GlobalUsings.cs, and applies to every other file in the project. With both features enabled, a typical service file looks almost empty, and the using directives for namespaces like System, System.Collections.Generic, and System.Linq no longer appear in every file. They are declared once and inherited everywhere, which reduces duplication dramatically for teams shipping microservices across multiple projects.

Australian teams building Azure hosted solutions in the Australia East and Australia Southeast regions often standardise a template that bundles both features. The shared project file includes a single <Using Include="..." /> entry for each common namespace, and every new file starts with just a namespace line.

Working in mixed codebases during migration

Most large codebases cannot migrate in a single sitting. Old files keep block scoped namespaces while new files use the file-scoped form, and both compile in the same project without conflict. The visual mix can feel inconsistent during review, but incremental adoption remains safe.

One pragmatic approach is to migrate a folder at a time, starting with leaf directories that contain generated code or test files. Once a folder is converted the review discipline stays consistent within that part of the tree. Melbourne's .NET community has shared notes about doing folder by folder migrations over a sprint or two without breaking feature branches.

Build agents should be updated to use .NET 6 or later before any migration starts, since earlier SDKs do not understand the new syntax. A simple target framework bump in the csproj is enough. The feature is forward compatible, so older toolchains still work during the very early phase.

Pairing the feature with editorconfig enforcement

Style rules live most happily in an editorconfig file. Adding csharp_style_namespace_declarations = file_scoped:suggestion (or warning, or error) makes Visual Studio and Rider flag any new file that uses block scoped namespaces. The setting is read by both IDEs, so the rule applies regardless of which tool a developer prefers.

For larger organisations with distributed teams across Sydney and Adelaide, hosting the editorconfig in a shared repository and referencing it from each solution keeps the style consistent. A small dotnet format check in the CI pipeline catches drift before it lands on main. The whole setup takes less than an hour to configure.

Reference material is available through the C# Corner conference, where sessions cover language updates and team workflow. Engineers picking modern C# patterns find the agenda useful without reinventing the wheel.

Best practices and common pitfalls

Keep one type per file when adopting file-scoped namespaces. The feature only makes sense if every type in the file shares the same namespace, which is the dominant convention in C# projects. Files that already violate this rule may need a small rethink.

Avoid mixing the two styles within the same project for too long. A long migration window creates confusion during onboarding, since new hires learn one style from older files and another from newer ones. Pick a date, convert the whole tree, and move on.

Watch out for preprocessor directives that wrap large blocks of code. Conditional compilation sections sometimes rely on the closing brace of a namespace to terminate their scope. With file-scoped namespaces those braces disappear, so any large region blocks need a once over. A quick build with each configuration combination catches any oversights.

Treat file-scoped namespaces as a default rather than a religion. Generated files, interop wrappers, and odd partials sometimes read better in the old style. The compiler accepts both, and so should reviewers. Consistency across the project is what matters.