是否有关于类结构顺序的正式 C＃准则？
它会去吗：
我很好奇，关于项目顺序是否有严格的规定？我到处都是。我想坚持一个特定的标准，所以我可以在任何地方做到这一点。
真正的问题是我的更复杂的属性最终看起来很像方法，并且它们在构造函数之前的顶部感觉不合适。
有任何提示 / 建议吗？
根据StyleCop 规则文档，顺序如下。
在类，结构或接口中：（SA1201 和 SA1203）
在以下每个组中，按访问顺序排序：（SA1202）
在每个访问组中，先按静态，然后按非静态顺序排序：（SA1204）
在每个静态 / 非静态字段组中，按只读顺序排序，然后按非只读顺序排序：（SA1214 和 SA1215）
展开的列表长 130 行，因此在这里我不会展开。展开的方法部分是：
该文档指出，如果规定的顺序不合适（例如，正在实现多个接口，并且应该将接口方法和属性分组在一起），则可以使用部分类将相关的方法和属性分组在一起。
与其按可见性或按项目类型（字段，属性，方法等）分组，不如按功能分组？
这是一个古老但仍然非常相关的问题，因此，我将添加以下内容：打开以前可能已经读过或未曾阅读过的类文件时，您要寻找的第一件事是什么？田野？特性？我已经从经验中意识到几乎总是要去寻找构造函数，因为最基本的要了解的是如何构造该对象。
因此，我开始将构造函数放在类文件中的第一位，并且从心理上看，结果是非常积极的。将构造函数放在一堆其他事情之后的标准建议让人感到不协调。
C＃6 中即将推出的主要构造函数功能提供了证据，证明构造函数的自然位置位于类的最上层 - 实际上，甚至在大括号之前也已指定了主要构造函数。
有趣的是，像这样的重新排序有多大的不同。它使我想起以前如何using语句来进行排序 - 首先使用 System 名称空间。 Visual Studio 的 “整理使用情况” 命令使用了此顺序。现在， using s 只是按字母顺序排序，而没有对 System 命名空间进行特殊处理。结果感觉更简单，更干净。