Should we put classes, enums and other entities to their's own files? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

I had a discussion with our's company teamlead\architect on this topic.

He argues that it is easier to understand the large-scale project if "entities connected by logic" are placed in one cs-file.

I quote:

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

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

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

In my opinion:

Small enums and classes that are needed inside a bigger logical class can stay in its file.
But if the smaller classes and enums are used outside of that scope, you should have them separately (although if they are logically linked they themselves could be in the same file).
So I agree with him about the logical coupling.

Saying that, i must say that there are other alternatives, you can create logical folders inside a project to hold classes from the same logical environment or connections.
The IDEs today give you easy access and mobility throughout the solution with Go-To functionality, so finding the code isn't a problem.

Keeping logical components together (as long as they are really closely coupled) does have a big advantage when scaling. As the project gets bigger it tends to get more of a mess, and that's exactly what he's trying to avoid.

BTW, if you read Skeet's opinion closely you'll notice:

and assuming they're going to be used by other classes, make them top-level types in their own files.

Answer 2

This is very much a matter of opinion, and so would be better posted here:

https://codereview.stackexchange.com/

However, usually you should place all types definitions in their own files, with some exceptions:

• A code contracts class used to provide contracts for an abstract base class or interface logically belongs with that class.

• An enum which is only used as a parameter, property or return value within a class also belongs with that class (but not nested within it).

There are probably a few other exceptions, but in general each type should go into a separate file.

Answer 3

Interesting question, this is my take on it.

You have to make a distinction between the logical grouping (namespace) and the physical grouping (file/project).

In any case, an enumeration should be put in the logical namespace it business wise belongs to, not in a namespace that only contains enumerations, or don't even specify enumeration in the namespace name. It doesn't make sense to have an 'Enums' namespace, as you will then be cluttering concepts and you don't specify the domain it belongs to.

If an enumeration is used by only one type of class, you can also put it in the class itself. This way, it is clear that it belongs to that particular class and as such it is in the same code file. If the enum is more like a general purpose enum, used in multiple classes, then put it separate in its own code file.

So I disagree with your team lead: if you put it in the same file, make it part of the class itself because that's what you are actually saying if you put it in the same file, otherwise put it in its own code file. I think it's somehow more consistent usage anyway.

Answer 4

i think that your "teamlead\architect" opinion is largely based on poor usages of namespaces. every time I have heard that argument from a developer it is because of almost total lack of namespace usage(and then it becomes really messy if you add a lot of files)

Answer 5

You and him can take a look at a large number of complex open source projects on Internet. Look at github, codeplex and similar places.

For example look at MVC source code. If class-per-file is good enough for Microsoft and as complex a project as MVC, I think there is a good chance it would also be good enough for you guys.

Personally I use class/interface per file approach (except in particular cases, like having a little enum, but that subjective) and I don't see any problems with it.

Answer 6

I disagree with many points made by the "teamlead/architect" here.

Like a lot of things to do with code, it is a matter of opinion.

Personally, I believe it is best to create one .cs-file per enum, class and so on. Usually if there's one class that's most closely associated with the enum, and I put them in the same file.

I accept that companies can have their own coding standard but the one suggested here is just plain wrong as it goes against a lot of what I would consider good practice.