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

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

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

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

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

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

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

我更喜欢将私有字段与构造函数一起放在顶部，然后将公共接口位放在后面，然后是私有接口位。

此外，如果您的类定义足够长，以至于项的顺序变得很重要，这可能是一种代码气味，表明您的类太庞大和复杂，您应该重构。

通常我会遵循下面的模式:

静态成员(通常有其他上下文，必须是线程安全的，等等) 实例成员

每个部分(静态和实例)由以下成员类型组成:

运算符(总是静态的) 字段(在构造函数之前初始化) 构造函数 析构函数(是遵循构造函数的传统) 属性 方法 事件

然后成员按可见性排序(从低到高):

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

顺序不是教条:简单的类更容易阅读，然而，更复杂的类需要特定于上下文的分组。

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

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

常量 静态变量 字段 事件 构造函数(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; }
}