7

Which is better: many class definitions in same file or every class definition in separate file?

Examples:

1) Many classes in same file. Say, myManyClasses.cs:

namespace myPack
{
   class myClass1()
   {
   }
   class myClass2()
   {
   }
   class myClass3()
   {
   }
  . 
  . 
  .
}

2) Every class in separate file:

myClass1.cs

namespace myPack
{
   class myClass1()
   {
   }
}

myClass2.cs 

 namespace myPack
 {
   class myClass2()
   {
   } 
 }

. . .

Improve this question
4

7 Answers 7

Reset to default
22

Every class in a different page of course. Unless the class is ridiculously small or related only to one class that is the main class in the file.

Improve this answer
2
  • 1
    care to give reason?
    – Louis Rhys
    Sep 12, 2012 at 2:13
  • So you can just use the file name to see / open the class and you don't need to remember where was that class. Although in visual studio its become super easy to quickly find / open a class definition but still its a bit messy when you have a file open and see a large set of "unrelated" classes and wonder why they are in the same file.
    – basarat
    Sep 12, 2012 at 16:11
10

I keep each class in a single file because

  • it makes it easier to navigate in the Solution Explorer
  • it offers a better granularity when working with version control systems, especially those where you have a locking checkout mechanism for editing files; you need to lock only the code for the class you are editing.
  • it follows the most common convention, making it easier for new developers to find their way around

The only exception I make to this rule is that I sometimes put enums into a a common Enums.cs file, since they typically are super small, rarely updated and contain no logic. I used to do the same with delegates, but since the generic Func and Action delegates came along, it's extremely rare that I define my own delegates.

Improve this answer
2

One class per file.

It has many pros in Visual Studio. For example, if you change file name, it'll prompt you to automatically change class name.

Anyway, because we're in a programming era where refactoring is a everyday's task, a good naming convention and an assembly member per file would make things easier to handle if you've to improve, change or revamp your source code. And it can be less confusing for your project development newbies!

Improve this answer
2

One class per page is better, but sometimes where tha class is very small and only used inside the same class file, well, i think is self explanatory.

Improve this answer
2

I prefer to structure my code to avoid cyclical dependencies between source files. In general, I put a single class in a source file, but if I have two or more tightly coupled classes, I will collect them in a single file. However, in that case I would be strongly inclined use inner classes if possible.

Improve this answer
2

Most programmers seem to agree that one class per file is the way to go. I happen to agree.

If you have multiple classes in one file, you are just making it harder to find anything in that file.

Improve this answer
1

I much prefer having one class per file.

The reason is that I can locate the class files more easily in Solution Explorer. I don't have to look at the class view to find the class.

Also, as your application grows, it is likely that the classes will grow as well. They will get more properties and methods. What started out as a small class could evolve into one that is quite large. At that point, it would be awkward to move the class code into a separate file.

Improve this answer
1
  • 3
    if your classes grow together with your application they probably violate the Single Responsability Principle
    – stijn
    Mar 11, 2011 at 19:57