Is it a bad practice to have multiple classes in the same file?

Question

I used to have one class for one file. For example car.cs has the class car. But as I program more classes, I would like to add them to the same file. For

Answer 1

You should refrain from doing so, unless you have a good reason.

One file with several small related classes can be more readable than several files. For example, when using 'case classes', to simulate union types, there is a strong relationship between each class. Using the same file for multiple classes has the advantage of grouping them together visually for the reader.

In your case, a car and a door do not seem related at all, and finding the door class in the car.cs file would be unexpected, so don't.

Answer 2

The rule I always go by is to have one main class in a file with the same name. I may or may not include helper classes in that file depending on how tightly they're coupled with the file's main class. Are the support classes standalone, or are they useful on their own? For example, if a method in a class needs a special comparison for sorting some objects, it doesn't bother me a bit to bundle the comparison functor class into the same file as the method that uses it. I wouldn't expect to use it elsewhere and it doesn't make sense for it to be on its own.

Answer 3

As is true so much of the time in programming, it depends greatly on the situation.

For instance, what is the cohesiveness of the classes in question? Are they tightly coupled? Are they completely orthogonal? Are they related in functionality?

It would not be out of line for a web framework to supply a general purpose widgets.whatever file containing BaseWidget, TextWidget, CharWidget, etc.

A user of the framework would not be out of line in defining a more_widgets file to contain the additional widgets they derive from the framework widgets for their specific domain space.

When the classes are orthogonal, and have nothing to do with each other, the grouping into a single file would indeed be artificial. Assume an application to manage a robotic factory that builds cars. A file called parts containing CarParts and RobotParts would be senseless... there is not likely to be much of a relation between the ordering of spare parts for maintenance and the parts that the factory manufactures. Such a joining would add no information or knowledge about the system you are designing.

Perhaps the best rule of thumb is don't constrain your choices by a rule of thumb. Rules of thumb are created for a first cut analysis, or to constrain the choices of those who are not capable of making good choices. I think most programmers would like to believe they are capable of making good decisions.

Answer 4

Since your IDE Provides you with a "Navigate to" functionality and you have some control over namespacing within your classes then the below benefits of having multiple classes within the same file are quite worth it for me.

Parent - Child Classes

In many cases i find it quite helpful to have Inherited classes within their Base Class file.

It's quite easy then to see which properties and methods your child class inherits and the file provides a faster overview of the overall functionality.

Public: Small - Helper - DTO Classes

When you need several plain and small classes for a specific functionality i find it quite redundant to have a file with all the references and includes for just a 4-8 Liner class.....

Code navigation is also easier just scrolling over one file instead of switching between 10 files...Its also easier to refactor when you have to edit just one reference instead of 10.....

Overall breaking the Iron rule of 1 class per file provides some extra freedom to organize your code.

What happens then, really depends on your IDE, Language,Team Communication and Organizing Skills.

But if you want that freedom why sacrifice it for an iron rule?

Answer 5

As a rule of thumb, one class/one file is the way to go. I often keep several interface definitions in one file, though. Several classes in one file? Only if they are very closely related somehow, and very small (< 5 methods and members)

Answer 6

One class per file is simpler to maintain and much more clear for anyone else looking at your code. It is also mandatory, or very restricted in some languages.

In Java for instance, you cannot create multiple top level classes per file, they have to be in separate files where the classname and filename are the same.