Take the 2-minute tour ×

Should each class in my C# project get its own file (in your opinion)?

share|improve this question
I write pretty clean code, but this is something I never gave much thought to. I'd just put vaguely related classes in the same file. Thanks for your input! –  Christopher Sep 28 '08 at 14:43

10 Answers 10

up vote 67 down vote accepted

While the one class per file policy is strictly enforced in java, it's not required by C#. However, it's generally a good idea.

I typically break this rule if I have a very small helper class that is only used by the main class, but I prefer to do that as a nested inner class for clarity's sake.

You can however, split a single class into multiple files using the partial keyword. This is useful for separating your code from wizard-generated code.

share|improve this answer
Someone marked this post as offensive 5 times, which severerly docked me. Jeff, can you please sort this out. –  FlySwat Sep 28 '08 at 6:58
five different people, you mean –  Jeff Atwood Sep 28 '08 at 14:52
@Jonathan Holland: wizards offend some people :) –  user7116 Sep 28 '08 at 15:45
Maybe it is because Java does not force a single class per file. That is completely false. –  mmattax Sep 30 '08 at 21:45
Each file contains the definition of at most one PUBLIC top-level type. You can define as many top-level types as you like in a file, as long as they have package-private access. A rule of thumb is that if the helper is used ONLY by the public class, it can go in the same file. –  erickson Oct 30 '08 at 18:07

Files are cheap, you aren't doing anyone a favor by consolidating many classes into single files.

In Visual Studio, renaming the file in Solution Explorer will rename the class and all references to that class in your project. Even if you rarely use that feature, the cheapness of files and the ease of managing them mean the benefit is infinitely valuable, when divided by its cost.

share|improve this answer
I like the mathematical reinforcement of your conclusion ;) –  wprl Sep 28 '08 at 0:47
I like it too :) –  Andrei Rînea Sep 28 '08 at 17:53
very good argument –  geogeek Oct 17 '12 at 19:19

As others have said, one file per type in general - although where others have made the public/private distinction, I'd just say "one top-level file per type" (so even top-level internal types get their own files).

I have one exception to this, which is less relevant with the advent of the Func and Action delegate types in .NET 3.5: if I'm defining several delegate types in a project, I often bunch them together in a file called Delegates.cs.

There are other very occasional exceptions too - I recently used partial classes to make several autogenerated classes implement the same interface. They already defined the appropriate methods, so it was just a case of writing:

public partial class MessageDescriptor : IDescriptor<MessageDescriptorProto> {}
public partial class FileDescriptor : IDescriptor<FileDescriptorProto> {}

etc. Putting all of those into their own files would have been slightly silly.

One thing to bear in mind with all of this: using ReSharper makes it easier to get to your classes whether they're in sensibly named files or not. That's not to say that organising them properly isn't a good thing anyway; it's more to reinforce the notion that ReSharper rocks :)

share|improve this answer

It depends. Most of the time I would say yes, put them in separate files. But if I had a private helper class that would only be used by one other class (like a Linked List's Node or Element) I wouldn't recommend separating them.

share|improve this answer

I personally believe that every class should be in its own file, this includes nested types as well. About the only exceptions to this rule for me are custom delegates.

Most answers have excluded private classes from this rule but I think those should be in their own file as well. Here is a pattern that I currently use for nested types:

Foo.cs: // Contains only Foo implementation

public partial class Foo 
   // Foo implementation

Foo.Bar.cs: // Contains only Foo.Bar implementation

public partial class Foo
  private class Bar
    // Bar implementation
share|improve this answer
+1 for pointing out a clean transparent way of putting even nested types in their own files. (Not that I necessarily now feel compelled to do so...) –  Jon Coombs Sep 13 '13 at 22:08

Public classes: yes Private classes: (needless to say) no

share|improve this answer

They should be in different files, even when it seems like overkill. It's a mistake I still frequently make.

There always comes a time when you you've added enough code to a class that it deserves it's own file. If you decide to create a new file for it at that point then you lose your commit history, which always bites you when you lest want it too.

share|improve this answer

I actually prefer pretty big .cs files, 5000 lines is pretty reasonable IMO, although most of my files at the moment are only about 500-1000 (In C++, however, I've had some scary files), however, . The Object Browser/Class View, Go to Definition, and incremental search (-I; Thanks for that tip, Jeff Atwood!), all make finding any specific class or method pretty easy.

This is probably all because I am terrible about closing unneded tabs.

This is of course highly dependant on how you work, but there are more than enough tools to not need to use horrible old '70s based file source navigation (Joking, if it wasn't obvious).

share|improve this answer
Personally from a work point of view I find it more awkward to use a massive file than series of separate ones. Assuming they are sensibly named though, that's a bug bare of mine! A file name should reflect the class name IMHO. –  DazManCat Aug 2 '13 at 15:08

Of course! Why wouldn't you? Other than private classes it is silly to have multiple classes in a single file.

share|improve this answer

I think the one-class-per-file approach makes sense. Certainly for different classes, but especially for base and derived classes, whose interactions and dependencies are often non-obvious and error-prone. Separate files makes it straightforward to view/edit base and derived classes side-by-side and scroll independently.

In the days of printed source code listings running to many hundreds of pages (think of a phone book), the "three finger rule" was good a working limit on complexity: if you needed more than three fingers (or paper clips or post-its) as placeholders to understand a module, that module's dependency set was probably too complex. Given that almost no one uses printed source code listings anymore, I'll suggest that this should be updated as the "three window rule" - if you have to open more than three additional windows to understand code displayed in another window, this code probably should be refactored.

A class hierarchy of more than four levels is a code smell, which is in evidence if you need more than four open windows to see the totality of its behavior. Keeping each class in its own file will improve understandability for depth less than four and will give an indirect warning otherwise.

share|improve this answer

Your Answer


