最接近的可能是Brad Abrams的《设计指南、托管代码和。net框架》(http://blogs.msdn.com/brada/articles/361363.aspx)

这里概述了许多标准。我认为相关的章节是2.8。

这是一个古老但仍然非常相关的问题，所以我要补充一点:当您打开一个以前可能读过也可能没有读过的类文件时，您首先要查找的是什么?字段?属性呢?我从经验中意识到，我几乎总是去寻找构造函数，因为最基本的事情是理解这个对象是如何构造的。

因此，我开始在类文件中把构造函数放在前面，结果在心理上是非常积极的。将构造函数放在一堆其他东西后面的标准建议让人感觉不协调。

c# 6中即将出现的主构造函数特性提供了证据，证明构造函数的自然位置是在类的顶部——事实上，主构造函数甚至在开大括号之前就被指定了。

有趣的是，这样的重新排序会产生多大的不同。这让我想起了using语句过去是如何排序的——首先是System名称空间。Visual Studio的“Organize Usings”命令使用了这个顺序。现在使用只是按字母顺序排序，没有对系统名称空间进行特殊处理。结果就是感觉更简单、更干净。

我知道这是旧的，但我的命令如下:

公共的，受保护的，私人的，内部的，抽象的

常量 静态变量 字段 事件 构造函数(s) 方法 属性 代表

我还喜欢像这样写出属性(而不是简写方法)

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}

我建议使用IDesign的编码标准或Brad Abram网站上列出的编码标准。这是我找到的最好的两个。

布拉德会说……

类成员应该按字母顺序排列，并分组到部分(字段，构造函数，属性，事件，方法，私有接口实现，嵌套类型)

我已经重新构造了公认的答案，至于我认为是一个更好的布局:

在类、结构或接口中:

常数字段 只读的字段 字段 事件 属性 索引器 构造函数 终结器(析构函数) 接口(接口实现) 方法 类 结构体 枚举 代表

在这些组中，按访问顺序排列:

公共 内部 保护内部 受保护的 私人

在每个访问组中，按静态顺序，然后是非静态的:

静态 非静态

我还认为应该尽量减少嵌套类型。我经常看到人们有嵌套的类，枚举，委托，它们最好是一个单独的实例。使类型嵌套几乎没有任何好处。也要把它们放在单独的文件中。一个包含5个类的文件对我来说很混乱。

根据StyleCop规则文档，排序如下。

在类、结构或接口中:(SA1201和SA1203)

常数字段 字段 构造函数 终结器(析构函数) 代表 事件 枚举 接口(接口实现) 属性 索引器 方法 结构体 类

在这些组中，按访问顺序排序:(SA1202)

公共 内部 保护内部 受保护的 私人

在每个访问组中，依次按静态、非静态排序:(SA1204)

静态 非静态

在每个静态/非静态字段组中，按只读、非只读顺序排列:(SA1214和SA1215)

只读的 non-readonly

展开的列表有130行长，所以这里就不展开了。展开的方法部分为:

公共静态方法 公共方法 内部静态方法 内部方法 受保护的内部静态方法 受保护的内部方法 受保护的静态方法 受保护的方法 私有静态方法 私有方法

文档指出，如果规定的顺序不合适——比如，正在实现多个接口，并且接口方法和属性应该分组在一起——那么使用分部类将相关的方法和属性分组在一起。