Introduction

In .NET, “one class per file” is a convention, not a language rule. The C# compiler does not care how many classes share a file, but teams often prefer one class per file because it improves navigation, reduces merge conflicts, and makes code review easier.

Why the Convention Exists

A one-class-per-file layout makes a codebase easier to scan. When a file is named OrderService.cs, most developers expect the main type in that file to be OrderService.

That convention helps with:

• project navigation in IDEs
• source control diffs
• code search
• developer expectations

It is especially helpful in large codebases where many people are editing different parts of the same project.

The Compiler Does Not Require It

C# is perfectly happy with several classes in one file.

1public class Book
2{
3    public string Title { get; set; } = string.Empty;
4}
5
6public class Member
7{
8    public string Name { get; set; } = string.Empty;
9}

This compiles without any problem. So the real question is not “is it allowed,” but “does it help or hurt the maintainability of this project.”

When One Class Per File Works Best

The convention is strongest when:

• the type is important enough to change independently
• the class has meaningful behavior or state
• the class is public or part of a stable API
• the project is worked on by several developers

In those cases, a dedicated file usually improves clarity.

Example:

1// Book.cs
2public class Book
3{
4    public string Title { get; set; } = string.Empty;
5}

1// Member.cs
2public class Member
3{
4    public string Name { get; set; } = string.Empty;
5}

This structure is predictable and scales well.

When Multiple Types in One File Can Be Reasonable

There are still cases where several types in one file make sense.

Common examples include:

• tiny helper types tightly coupled to one main type
• private nested types
• a small interface plus a trivial implementation in an internal utility module
• records or DTOs that exist only to support one nearby feature

For example, a tiny internal helper may be clearer when it stays next to the type that uses it.

1public class ReportFormatter
2{
3    public string Format(LineItem item) => $"{item.Name}: {item.Count}";
4}
5
6internal record LineItem(string Name, int Count);

That can be perfectly reasonable if LineItem has no meaning outside that local context.

Partial Classes Are a Separate Case

Sometimes one logical class is deliberately split across files with partial. That is not a violation of the convention so much as a different organizational tool.

Common uses include:

• generated code plus handwritten code
• very large framework-integrated classes
• designer-generated UI code

The key point is that partial solves a different problem than grouping unrelated classes in one file.

Optimize for Clarity, Not Dogma

If a team rule says “one class per file,” it should be treated as a default, not as a mystical law. The goal is clearer structure, not mechanical obedience.

A good working rule is:

• default to one significant type per file
• break the rule only when colocating types clearly improves readability

That keeps the convention useful without turning it into ceremony.

Common Pitfalls

The most common mistake is treating one-class-per-file as if it were a compiler requirement rather than a design convention.

Another common issue is packing many unrelated classes into a single file and making navigation harder for the whole team. Developers also sometimes overcorrect in the other direction and split tiny tightly coupled helper types into separate files even when keeping them together would be clearer.

Summary

• .NET and C# do not require one class per file.
• It is a convention that usually improves readability and team workflow.
• Public or independently important types are strong candidates for their own files.
• Small tightly coupled helper types can sometimes stay together sensibly.
• Treat the rule as a default for clarity, not as a hard law.