One class per file rule in .NET? [closed]

Answer 1

I usually stick with one class per file. But I will make exceptions for groups of similar constructs that are used project-wide. For example:

• An EventArgs.cs that contains any EventArgs subclasses, since they're usually only 5-10 lines of code each, but they typically are used by several different classes. Alternatively, I might put the EventArgs classes in the same file as the class that declares the events.
• A Delegates.cs that contains Delegates that are used throughout the project, since they're usually only 1 line each. Again, the alternative is to put them in the same file with the class that exposes/consumes them.
• An Enums.cs that contains enums used throughout the project. (If there's an enum that's used only by one class, I'll usually make it private to that class.)

Answer 2

In the vast majority of cases, I follow the one class per file rule. The only exception I regularly make is the definition of an enum that is tightly coupled to a specific class. In that one case, I will frequently include the enum's definition in that class' file.

Answer 3

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.

Answer 4

The responses so far seem to revolve around people's exceptions to the rule, so here's mine: I keep classes and their metadata 'buddy' classes together when using the DataAnnotations package in .NET3.5 SP1. Otherwise, they're always in seperate files. You know, most of the time. Except when they aren't.

Answer 5

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.

Answer 6

Another vote for one class per file with the file being named the same as the class. For me, it helps with long term maintainability. I can easily look through the repository and see what classes are part of a solution without having to open the project or any of the files.