类中项目的顺序：字段，属性，构造函数，方法

Question

是否有关于类结构顺序的正式C＃准则？

它会去吗：

公共领域

私人领域

性质

建设者

方法

？

我很好奇，关于项目顺序是否有严格的规定？我到处都是。我想坚持一个特定的标准，所以我可以在任何地方都可以做到。

真正的问题是我的更复杂的属性最终看起来很像方法，并且它们在构造函数之前的顶部感觉不合适。

有任何提示/建议吗？

Answer 1

根据StyleCop规则文档，顺序如下。在类，结构或接口中：（SA1201和SA1203）常数场领域建设者终结器（析构函数）代表们大事记枚举接口（接口实现）性质索引器方法结构班级在以下每个组中，按访问顺序排序：（SA1202）上市内部受保护的内部受保护的私人的在每个访问组中，先按静态，然后按非静态顺序排序：（SA1204）静态的非静态在每个静态/非静态字段组中，按只读顺序排序，然后按非只读顺序排序：（SA1214和SA1215）只读非只读展开的列表长130行，因此在这里我不会展开。展开的方法部分是：公共静态方法公开方法内部静态方法内部方法受保护的内部静态方法受保护的内部方法受保护的静态方法受保护的方法私有静态方法私人方法文档指出，如果规定的顺序不合适（例如，正在实现多个接口，并且应该将接口方法和属性分组在一起），则可以使用局部类将相关的方法和属性分组在一起。

Answer 2

这是一个古老但仍然非常相关的问题，因此，我将添加以下内容：打开以前可能已经读过或未曾阅读过的类文件时，寻找的第一件事是什么？田野？属性？我从经验中意识到，几乎总是要去寻找构造函数，因为最基本的要了解的是如何构造该对象。因此，我已经开始将构造函数放在类文件中，并且从心理上来说，结果是非常积极的。将构造函数放在一堆其他事情之后的标准建议让人感到不协调。C＃6中即将推出的主要构造函数功能提供了证据，证明构造函数的自然位置位于类的最上层-实际上，甚至在开括号之前也已指定了主要构造函数。有趣的是，像这样的重新排序有多大的不同。它使我想起以前如何对using语句进行排序-首先使用系统名称空间。Visual Studio的“组织使用”命令使用了此顺序。现在，usings仅按字母顺序排序，而没有对System命名空间进行特殊处理。结果感觉更简单，更干净。

Answer 3

通常我会尝试遵循以下模式：静态成员（通常具有其他上下文，必须是线程安全的，等等）实例成员每个部分（静态和实例）由以下成员类型组成：运算符（始终是静态的）字段（在构造函数之前初始化）构造函数析构函数（是遵循构造函数的传统）属性方法大事记然后，成员按可见性排序（从不可见到更可见）：私人的内部内部保护受保护的上市顺序不是教条：简单的类更易于阅读，但是，更复杂的类需要特定于上下文的分组。