In computer science courses at University, assignments written in OO languages such as Java had file systems similar to this:

  • TreeNode.java
  • BinaryTree.java
  • Assignment1.java
  • etc. ...

In writing some of my own projects, it seems like splitting up each class into a file is very trivial, especially when classes are very small. Are there other design patterns that circumvent having many files lots of small helper classes, or is this pretty much the only standard?

  • 1
    You may want to adjust your thinking as you learn programming. Programming is all about breaking large problems into smaller ones; small classes, small files, and small methods are preferred over large ones in most cases. You might even find classes broken into more than one file each in order to keep them a reasonable size. There is nothing more organized about one big file-- indeed, a "one file does all" approach is a good way to create spaghetti code. If this remains counterintuitive to you your work will be very difficult.
    – John Wu
    Commented Feb 5, 2019 at 0:40

1 Answer 1


"One class per source file" is the general standard for C# and Java.

Version control software operates with files, and not with classes. If you have one class per file, then you'll be able to see at a glance down to an individual class where you have been making changes.

For your own project, this is more important than for academic assignments. Your own project will be long-lived, and the functionality of the classes will grow.

Just last week, I had to do maintenance on 3rd party C# code. It had a 2.5kloc source file with five (5) large classes inside, and one of them had a substantial nested class. I've split that source file into five separate ones. That was one one of the first things I've done during that maintenance session.

Similar question. Which is better: many class definitions in the same file or every class definition in a separate file?

Not the answer you're looking for? Browse other questions tagged or ask your own question.