I just wondered what other peoples thoughts were regarding related classes in a single or separate .cs file?
If, for example, I have an interface that is implemented by, say an arbitrary 10, other classes, would you place them all in the same file or separate them?
Thanks.
I always go with separate files for each class. It's recommended best practice and it really makes sense.
My approach is that 1 file == 1 class/interface/module/... whatever. So the filename always reflects what's in there. To me that's the cleanest approach.
I would separate classes into different files. This makes them a lot easier to find in the IDE.
I would place each class in a separate file, and the interface in a separate file as well.
I would give the file the following name .cs
That's a recommended best practice; it allows you to find your classes very fast. I always go with this approach (except when I have inner classes offcourse. :) ).
I must agree with the rest here: 1 class = 1 file.
Also use correct namespacing for full project name as well as folders. Interfaces also go into separate files, but I usually keep enums and structures inside other classes.
Folders can be used to group certain classes together. There is however a small issue when you "run out of names" so to speak.
Example:
Solution: Tedd.CoolApp
Project: Tedd.CoolApp.Engine
Now what do I name the class? I want to name it Engine
, but that would give me Tedd.CoolApp.Engine.Engine
... :)
The computer could care less about the folder structure you concoct, so this question definitely falls under the category of code readability. As mentioned in this post about standards of code readability , friendly naming , consistency , and logical code separation are fundamental to the creation of readable code.
So, where does that leave us? The creation of files--and the creation of namespaces and file regions--should be consistent. The names should be understandable. And the code in each aggregate category should have something in common, as should be detailed in the category name. Ultimately, with readability, you're considering that your code might be inherited by another poor fellow, and that the naming standards that you've created might help that poor fellow (a "tourist developer", if you will) more easily navigate around in the madness.
That's a lot of talking, so let me get down to brass tacks. These are my rules, but I think they might be helpful to those who are looking to clean up their own code aquariums:
namespace FatDish.Engines//.EngineExtensions { ...
When it comes to navigability, the first and second rule are key, as they directly aid in indicating to the "tourist developer" where any given piece of code resides.
That's all I can think of at the moment. It's more important that you're consistent in your conventions than it is that you adopt any particular form of conventionality. That will help other developers understand and consume your code at a quicker rate, and ensure that future developments in the project (written by folks other than yourself) stay within the same conventional, coherent bounds that you've established.
Hope this helps!
Personally I adhere to Single Responsibility Principle where each of my classes has a single behaviour
think of a ecommerce site that has
I would separate these out to a User class, Billing Class and Orders class - the same would then adhere for an interface driven approach - 1 interface for each Responsibility
check out SOLID design principles - each class would then be in owns own file and have a suitable naming convention to help
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.