Is it necessary to put enum, class in separate files always?

Question

.NET

Hello.
Here we argued with our architect / team leader on this topic.
He argues that it is easier to understand a large project if the "entities united by logic" are folded into a single .cs file.
I quote:

• “The whole structure of logic and interfaces and the class can be seen in one place, this is an argument that cannot be refuted by anything. to see the same thing, but taking into account the scatter across files, you need to use tools, class diagram, R# for navigation, etc.”
  
• “on a bare theory, I can also sum up for a long time that a separate file is cool, but when it comes to making changes to existing code, especially if it’s not written by you, which is scattered over 3 files, it’s already a disaster, and when the code is scattered over 20 or more files , "I would have killed." So on the forums you can also write that one exception is one file, but in practice this should never be used.
  
• "... sharing between developers in the current use of TFS does not pose any problems, it is possible to edit the same file at the same time"
  

Everywhere they write that one enum, class - one file - this is best practice.
Links may not be provided.
What do you think? Is there a real problem here? Or is it a matter of taste and should be governed by the organization's coding standard?

Answer 1

One class is one file, and an enum and another class can be placed in a class. In my opinion, it improves the structure of the code.
Any rule built into an absolute can do more harm than good.

Answer 2

One file = One class or Struct. Sometimes (very rarely) I make exceptions for several Enums, but lately I try not to do that.
If I need to logically combine several entities into one heap, I create a folder in the project, and throw these entities into the folder. Of course namespace corresponds to a relative path.
We also have very heated debates about this in our company, so I can say for sure that recommendations are recommendations, but all people are different.
From the arguments in defense of my rule, I can give a very recent example. Now I'm dealing with a project that I entered only at the development stage of the second version, and in this project there were files with 10+ classes inside. Moreover, the files themselves sometimes bore a name that does not make it possible to unambiguously understand what is in this file. It was very difficult to figure out the architecture until the moment when I gradually brought everything to a normal structure with subfolders. Without this, the project is full of surprises - you move through it as if by touch, not having where you got after the next transition to the class and why.

Answer 3

I create my own file for each class, structure, interface, enumeration. I use folders for structuring. Doubts arise only with delegates who are already quite small.

Answer 4

Pure IMHO: in most cases, one class is one file. The enums used in this class are in the file of the class itself. I make an exception only for small classes-heirs. For example, if there is a base class, and many small classes-successors (each with 1-2 new fields, most classes are just containers) - then they were put into one file.

Answer 5

There is a problem, but its roots do not stretch from here. I'll try to explain with an example, let's imagine: there is a file with two classes in the project for 5k lines, the project has a history and a shift of programmers. Over time, the file has grown and someone Pupkin decides to share it. It's a simple matter - a new file is added to the project, one of the classes is transferred to it, commit. At this point, the edit history of the migrated class is lost.
If each Pupkin could correctly clone a file in a turnip, and then divide it while preserving the history of changes, to facilitate understanding, there would indeed be correctly connected entities in one place, but in real life we ​​are not given such happiness. A new character can come to the project at any time, the level of competence is unpredictable in advance, so I consider it tactically more intelligent to divide everything into files. I make an exception only for enum and delegate declared together with the interface where they are used.

Answer 6

More objective than just IMHO, you should not expect.
The position is the same, why you should not store all the files in one folder - the time for comprehension and processing is more important than the saved splits.
Moreover, if exactly one other element is guaranteed to use a certain element, it makes sense to throw them into one piece of code.

Answer 7

For each class, structure and enumeration, like colleagues above, I make a separate file.
True, there are also reverse exceptions, when a class has to declare partial and implement a heavy (3000+ lines) interface separately.