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

Answer 1

I, too, believe there should be one type included in a single file.

There is one exception to this rule that must be mentioned: Having two classes that differ only by a generic argument such as:

RelayCommand     

and

RelayCommand<T>

Answer 2

Beyond hypothetical arguments and focusing instead on Windows .NET with Visual Studio IDE and growing software projects, it just makes sense in this context to have one class per file.

---

In general, for visual reference nothing beats one class per file. Really.

I don't know if Microsoft does or doesn't do the same, however they did create the partial keyword to split one class over multiple files (this is even more severe). It's often used to split the auto-generated designer code from your custom code in the same class (but sometimes is used to allow different developers to work on the class at the same time via different files). So Microsoft does see benefits of multiple files and everybody has multiple file organization thoughts in mind for sure with .NET.

For nested classes you have no choice but to use one file, or at least the first parts of the classes in them. One file is necessary and fine in this case:

class BicycleWheel {
    class WheelSpoke {
    }
}

Otherwise why would you keep multiple classes in one file? The argument "because they're small" or associated with each other doesn't hold much water because eventually your classes will be associated with other classes. Ultimately you can't easily infer in-file organization of objects based on their usage especially as software continues to grow.

Additionally if you use folders for namespaces then you'll never have a class filename clash. It's also convenient to locate a class by filename on the file system when not inside a development environment like Visual Studio (e.g. if you want to quickly edit a class with Notepad or something quick/light).

So many good reasons...

Answer 3

Another reason for one-class-per-file that hasn't been mentioned in the answers posted so far is that one-class-per-file makes it easier to understand the impact of a PR during a code review. It also reduces merge conflicts.

When someone posts a PR for feedback I can look at the list of files changed and immediately see any overlap with what I might be working on. Depending on the overlap I might want to look at their code more deeply or give it an OK because I'm fairly confident it isn't going to affect my own changes.

When two people are working in a multi-class file and both add a dependency there's a good chance you'll get a merge conflict in the using block at the top. Separating the classes into files separates the dependencies so you can see what each class is using and you don't get conflicts like this.

There are exceptions to this rule (interface + implementation, enums, ...) but it's a better starting place than the opposite which typically lets junior developers bundle all manner of unrelated classes into the same file.

One-class-per-file is a clear unambiguous rule not subject to interpretation.

---

Related-classes-in-a-file is subject to personal preferences and interpretation (as you can see from all the other answers here as to when it's OK to use) and thus is a poor rule.

Answer 4

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

Answer 5

The back and forth has been very interesting, and seemingly inconclusive, though my general impression is that a 1-1 mapping between classes and files is the majority opinion, though with some person-by-person exceptions.

I'm curious if any of your answers vary depending on whether you are: (1) developing a Windows Forms app, a Web app, a Library, or whatever; or (2) using Visual Studio or not. In using VS, it would appear that the one class per file rule would also imply one class per VS project since the concensus in other threads seems to be that VS solutions/projects should be mirrored in the directory/file naming and structure. Indeed, my impression is that the concensus is to have the project name = assembly name = (nested) namespace name, all of which would then be mirrored in the directory/file naming and structure. If those are the right guidelines (or rules), then all these seemingly orthogonal organizing mechanisms would be nevertheless kept in sync.

Answer 6

On occasion I will leave a small class in with a larger class but only if they are very tightly related like an object and it's collection class or factory.

There is one problem with this though. Eventually the small class grows to the point at which it should be in its own file, if you move it to the new file you lose easy access to your revision history.

ie.

• on monday I make a change to my classes x and y in file y.css
• on tuesday I seperate class x in to its own file x.css because it has grow to large
• on wednesday my boss wants to see what I changed in class x on monday so he looks at the history for x.css, only x.css doesn't show the history before tuesdays changes.