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.
"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?