不是按可见性或按项目类型(字段、属性、方法等)分组，而是按功能分组呢?

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

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

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

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

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

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

静态 非静态

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

只读的 non-readonly

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

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

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

我的偏好是按种类排序，然后减少能见度如下

public methods
public events
public properties

protected methods
protected events
protected properties

private methods
private events
private properties
private fields

public delegates
public interfaces
public classes
public structs

protected delegates
protected interfaces
protected classes
protected structs

private delegates
private interfaces
private classes
private structs

我知道这违反了Style Cop，如果有人能给我一个很好的理由，为什么我应该把一个类型的实现细节放在它的接口之前，我愿意改变。目前，我强烈倾向于把私人成员放在最后。

注意:我不使用公共字段或受保护字段。

不是按可见性或按项目类型(字段、属性、方法等)分组，而是按功能分组呢?

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

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

我所看到的唯一编码指南是将字段放在类定义的顶部。

我倾向于把构造函数放在后面。

我的一般意见是，你应该坚持每个文件一个类，如果类足够大，属性和方法的组织是一个大问题，类有多大，你应该重构它吗?它是否代表多个关注点?