类中项目的顺序：字段、属性、构造函数、方法

根据StyleCop Rules Documentation，排序如下。

在类、结构或接口内：（SA1201 和 SA1203）

常量字段

字段

构造函数

终结器（析构函数）

代表们

活动

枚举

接口（接口实现）

特性

索引器

方法

结构

课程

在每个组中按访问顺序排列：（SA1202）

上市

内部的

受保护的内部

受保护

私人的

在每个访问组中，按静态排序，然后按非静态排序：(SA1204)

静止的

非静态

在每个静态/非静态字段组中，按只读排序，然后是非只读：（SA1214 和 SA1215）

只读

非只读

展开的列表有 130 行长，所以我不会在这里展开。展开的方法部分是：

公共静态方法

公共方法

内部静态方法

内部方法

受保护的内部静态方法

受保护的内部方法

受保护的静态方法

受保护的方法

私有静态方法

私有方法

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

---

与其按可见性或按项目类型（字段、属性、方法等）进行分组，不如按功能分组？

---

这是一个古老但仍然非常相关的问题，所以我将添加以下内容：当您打开一个您以前可能读过或可能没有读过的类文件时，您首先要查找的是什么？领域？特性？我从经验中意识到，我几乎总是在寻找构造函数，因为要了解的最基本的事情是这个对象是如何构造的。

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

C# 6 中即将推出的主构造函数特性证明了构造函数的自然位置是在类的最顶端 - 事实上，主构造函数甚至在左大括号之前就已指定。

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

---

我不了解语言或行业标准，但我倾向于按此顺序排列，每个部分都包含在#region 中：

使用语句

命名空间

班级

私人会员

公共财产

构造函数

公共方法

私有方法

---

我建议使用 IDesign 中的编码标准或 Brad Abram's website 中列出的标准。这是我找到的最好的两个。

布拉德会说...

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

---

通常我会尝试遵循下一个模式：

静态成员（通常具有其他上下文，必须是线程安全的，等等）

实例成员

每个部分（静态和实例）由以下成员类型组成：

运算符（始终是静态的）

字段（在构造函数之前初始化）

构造函数

析构函数（是遵循构造函数的传统）

特性

方法

事件

然后成员按可见性排序（从少到多可见）：

私人的

内部的

内部保护

受保护

上市

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

---

如前所述，C# 语言中没有任何内容规定布局，我个人使用区域，并且我为普通班级做类似的事情。

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

无论如何，这对我来说很有意义

---

我的偏好是按种类订购，然后按如下方式降低知名度

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

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

---

来自 StyleCop

私有字段、公共字段、构造函数、属性、公共方法、私有方法

由于 StyleCop 是 MS 构建过程的一部分，您可以将其视为事实上的标准

---

您可能找到的最接近的是 Brad Abrams 的“设计指南、托管代码和 .NET 框架”(http://blogs.msdn.com/brada/articles/361363.aspx)

这里列出了许多标准。我认为相关部分是2.8。

---

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

此外，如果您的类定义足够长以至于项目的排序很重要，那么这可能是一个 code smell，表明您的类过于庞大和复杂，您应该重构。

---

我尽可能简单（至少对我来说）

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

---

我知道这是旧的，但我的订单如下：

按照公共、受保护、私有、内部、抽象的顺序

常数

静态变量

字段

活动

构造函数

方法

特性

代表们

我也喜欢写出这样的属性（而不是速记方法）

// 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; }
}

---

我见过的唯一建议的编码准则是将字段放在类定义的顶部。

我倾向于将构造函数放在下一个。

我的一般意见是你应该坚持每个文件一个类，如果类足够大以至于属性与方法的组织是一个大问题，那么类有多大，你是否应该重构它？它是否代表了多重关注？

---

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

---

关于我认为更好的布局，我已经重组了接受的答案：

在类、结构或接口中：

常量字段

只读字段

字段

活动

特性

索引器

构造函数

终结器（析构函数）

接口（接口实现）

方法

课程

结构

枚举

代表们

在这些组中的每一个中，按访问顺序排列：

上市

内部的

受保护的内部

受保护

私人的

在每个访问组中，按静态排序，然后按非静态排序：

静止的

非静态

我也觉得嵌套类型应该保持在最低限度。我经常看到人们有嵌套的类、枚举、委托，它们最好是一个单独的实例。使类型嵌套几乎没有任何好处。也将它们放在单独的文件中。一个包含 5 个类的文件让我感觉很混乱。

---