Should classes, enums and other entities be placed in separate files?

Question

My company's team lead\architect argues that a large-scale project is easier to understand if "entities connected by logic" are placed in one .cs file.

I quote:

• "The whole structure of the logic and the interface and the class can be seen in one place, this is an argument which can't be refute. To see the same thing but with a bunch of files you need to use the tools, class diagram, R# for navigation, etc."

• "Following the poor theory I might scream that an army of separated files is cool, but when it comes to making changes to the existing code, especially if you were not a writer of this code, it's very difficult to understand plenty of scattered files. So on forums, you can write that "one enum- one file", but in practice this approach should never be used "

• "... As to the separation of code base between developers, nowadays it's not a problem edit simultaneously the same file. The merge is not a problem."

I heard and read many times that we have to create one .cs file per enum, class and so on and this is the best practice.

But I can't convince him. He says that he don't trust to any well-known programmers such as Jon Skeet. By the way here is Skeet's opinion on this topic: Where is the best place to locate enum types?

What do you think? Is there a real problem? Or is it a matter of taste and should be regulated by the coding standard of the organization?

Answer 1

There are a couple of flaws in your Team Lead's argument:

1. Well-designed classes and enums are intended to be used anywhere in your project, not just where they may make sense logically.

2. Classes and enums that are properly documented with XML comments are very self-describing, by merely hovering over the item referencing it.

3. You can always get to a class or enum definition by right-clicking the reference and selecting "Go to Definition," so it really shouldn't matter where you put it.

4. Putting objects together in a "logical" fashion is arbitrary (i.e. you have to think about what "logical" means. I'd rather expend those clock cycles doing actual programming).

Setting up each object definition in its own file creates a uniform, disciplined expectation of organization and structure, and doesn't raise questions like "why is this here?" That's a very nice thing to have.

If two or more objects are logically related, simply put them in their own folder in the Project Explorer.

Answer 2

Most likely the team lead cut his teeth in an earlier era when right clicking and choosing "go to definition" wasn't an option. I know when I'm in heavy spike development mode I will grow pretty massive class files until I let resharper fix it for me.

In any case, if you wanted to take the team lead to task, ask him why these classes and enums aren't child classes and enums -- no reason to declare them as independent entities if they are truly dependent entities. This might help him think the fatwa through a bit.