Menu
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:
"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?
464
If the enum is only used within one class, it should be placed within that class, but if the enum is used between two or more classes, it ought to either be in it's own code file, or in a conglomerated code file that contains all the enum for a particular assembly.
You don't have to declare an enum in a separate file.
Declaration of enum in Java: Enum declaration can be done outside a Class or inside a Class but not inside a Method.
You should use enum types any time you need to represent a fixed set of constants. That includes natural enum types such as the planets in our solar system and data sets where you know all possible values at compile time—for example, the choices on a menu, command line flags, and so on.
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.
133
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.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
