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

是否有关于类结构顺序的正式C＃准则？

它会去吗：

• 公共领域
• 私人领域
• 物产
• 建设者
• 方法
  ？

我很好奇，关于项目顺序是否有严格的规定？我到处都是。我想坚持一个特定的标准，所以我可以在任何地方都可以做到。

真正的问题是我的更复杂的属性最终看起来很像方法，并且它们在构造函数之前的顶部感觉不合适。

有任何提示/建议吗？

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

在类，结构或接口中：（SA1201和SA1203）

• 常数场
• 领域
• 建设者
• 终结器（析构函数）
• 代表们
• 大事记
• 枚举
• 接口（接口实现）
• 物产
• 索引器
• 方法
• 结构
• 班级

在以下每个组中，按访问顺序排序：（SA1202）

• 上市
• 内部
• 受保护的内部
• 受保护的
• 私人的

在每个访问组中，先按静态，然后按非静态顺序排序：（SA1204）

• 静态的
• 非静态

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

• 只读
• 非只读

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

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

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

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

这是一个古老但仍然非常相关的问题，因此，我将添加以下内容：打开以前可能已经读过或未曾阅读过的类文件时，寻找的第一件事是什么？田野？属性？我已经从经验中意识到，几乎总是要去寻找构造函数，因为最基本的要了解的是如何构造该对象。

因此，我已经开始将构造函数放在类文件中，并且从心理上来说，结果是非常积极的。将构造函数放在一堆其他事情之后的标准建议让人感到不协调。

C＃6中即将推出的主要构造函数功能提供了证据，证明构造函数的自然位置位于类的最上层-实际上，甚至在开括号之前就指定了主要构造函数。

有趣的是，这样的重新排序会带来多大的变化。它使我想起以前如何对using语句进行排序-首先使用系统名称空间。Visual Studio的“组织使用”命令使用了此顺序。现在，usings仅按字母顺序排序，而对System名称空间没有任何特殊处理。结果感觉更简单，更干净。

我不了解某种语言或行业标准，但我倾向于按以下顺序将各个部分放在#region中：

使用语句

命名空间

类

私人会员

公共财产

建设者

公开方法

私人方法

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

布拉德会说...

类成员应按字母顺序排列，并分为几节（字段，构造函数，属性，事件，方法，专用接口实现，嵌套类型）

如前所述，C＃语言中没有任何内容可以规定布局，我个人使用区域，而对于普通班级，我会这样做。

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

反正对我来说很有意义

从StyleCop

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

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

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

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

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

• 运算符（始终是静态的）
• 字段（在构造函数之前初始化）
• 构造函数
• 析构函数（是遵循构造函数的传统）
• 属性
• 方法
• 大事记

然后，成员按可见性排序（从不可见到更可见）：

• 私人的
• 内部
• 内部保护
• 受保护的
• 上市

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

我的偏好是按种类排序，然后降低可见度，如下所示

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 Framework”（http://blogs.msdn.com/brada/articles/361363.aspx）

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

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

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

我的一般评论是，您应该在每个文件中坚持一个类，如果该类足够大，以至于属性和方法的组织成为一个大问题，那么该类有多大，您是否应该重构它？它代表多个问题吗？

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

另外，如果您的类定义足够长，以至于项目的排序很重要，那么这可能是代码气味，表明您的类过于庞大和复杂，您应该进行重构。

我尽量保持简单（至少对我来说）

枚举
声明
构造 方法
重写
方法
属性
事件处理程序

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

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

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

• 常数
• 静态变量
• 领域
• 大事记
• 构造函数
• 方法
• 物产
• 代表们

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

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