我不知道哪种语言或行业标准，但我倾向于按照这样的顺序排列，每个部分都用#区域包装:

使用报表

名称空间

类

私有成员

公共属性

构造函数

公共方法

私有方法

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

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

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

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

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

布拉德会说……

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

当然，语言中没有任何东西以任何方式强制执行它。我倾向于根据可见性(公共的，然后是受保护的，然后是私有的)对事物进行分组，并使用#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; }
}