One class per file rule in .NET?

I follow this rule but some of my colleagues disagree with it and argue that if a class is smaller it can be left in the same file with other class(es).

Another argument I hear all the time is "Even Microsoft doesn't do this, so why should we?"

What's the general consensus on this? Are there cases where this should be avoided?

I do this, but only when the classes are related in a child-parent fashion and the child classes are ONLY used by the parent.

In larger solutions I think it is very valuable to have one class per file and that the file is named the same thing as the class. It makes it much easier to locate the code you need to work in.

One class per file also gives you a better idea of what each check in is changing without looking at the diffs of the file.

`One case could be:` when your classes jointly form a `module / unit` that serves some main classes
like `helper classes`, other wise **no**.

have a look at [**ASP.NET MVC 2.0**][1] project source code. It strictly follows this rule


[1]:

[To see links please register here]

The StyleCop tool for C# has standard rules that require no more than one top-level class in one namespace (plus any number of interfaces, delegates and enums in that namespace).

In cases of two or more classes where the second and subsequent classes are only ever used by the first, those could and should be inner classes, visible only to the consuming class.