C# classes in separate files?

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.

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.

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 :)

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
  }
}

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.

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.

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

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).

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