How do you organize C# code in to files?

ぃ、小莉子 提交于 2019-12-02 23:06:27

Whatever you do, just PLEASE do it consistently. I don't believe there is any one single answer (though there are a few wrong ones). But just make sure you stay true to your form as this will be the key for your successor(s) to find things easily.

Currently I do:

  • One assembly for production code + unit tests
  • directory structure mimics namespaces
  • one type per file
    • nested types get their own file, using partial types. That is:


// ------ C.cs

public partial class C : IFoo
{
    // ...
}

// ------ C.Nested.cs
partial class C
{
    public class Nested
    {
        // ...
    }
}

I do it quite similarly. One point where I differ:

  • one type per file

I declare delegate types where I need them, i.e. not in their own file but rather in the class that uses them.

I create one assembly per architectural layer. (WinUI.exe, BusinessWorkflow.dll, BusinessComponent.dll etc.

Then, one physical file per class.

So that's "vertical".

Namespaces, conceptually, go horizontally, grouping domain level functionality together. All the customer stuff goes in a "Customer" namespace, say, Orders go in "Accounting.AccountsPayable" for example.

As each assembly only reference the one beneath it in - architecturally, your intellisense is constrained nicely by relevant references within your domain model.

(Have to agree with above though - consistency is vital.

For tiny projects with less than a dozen classes, just one class per file.

For enterprise projects, I have multiple projects in a solution. They are grouped by purpose (business classes, interfaces, UI). Each class has its own file.

No matter how small a type is, put each type into a separate file - Exception: nested classes and delegates

By the way, using a partial class to separate for the sole purpose of placing a nested type in its own file seems like an overkill. Partial classes should be used judiciously and typically to be used for file generation tools - You have to consider how to "name" your partial classes for nested classes. Coming up with an intuitive name for physical nested file can be tidious and it is definately not a simple task.

For projects, name your projects to reflect namespaces - Exception: When a nested namespace gets big, I would migrate a nested folder into another project.

I prefer the conventional one-file-per-public-class, with folders inside the project (which map to sub-directories) used to group conceptually related classes as needed to keep the Solution Explorer view manageable. If your class names are well chosen the folders shouldn't be strictly necessary, but they are helpful if the project has a lot of classes.

Using separate files for nested types seems like overkill, at least if the nested classes are relatively simple 'helper' classes, and particularly so if they are private.

The main practical objection to your friend's "everything in one huge file" scheme is that Visual Studio tends to get very, very slow when it tries to deal with very long code files.

I prefer this kind of organization in whatever language.

Related small classes in their own file(s).

Big classes in their own file.

Directories for separate subprojects.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!