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

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

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

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

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，如果有人能给我一个很好的理由，为什么我应该把一个类型的实现细节放在它的接口之前，我愿意改变。目前，我强烈倾向于把私人成员放在最后。

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

我尽量让它简单(至少对我来说)

枚举 声明 构造函数 覆盖 方法 属性 事件处理程序

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

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

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

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

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

布拉德会说……

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

当然，语言中没有任何东西以任何方式强制执行它。我倾向于根据可见性(公共的，然后是受保护的，然后是私有的)对事物进行分组，并使用#regions对相关的事物进行功能分组，而不管它是属性、方法还是其他什么。构造方法(无论是实际的ctor还是静态的工厂函数)通常是在顶部，因为它们是客户需要知道的第一件事。