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

Question

在课程结构方面是否有关于项目顺序的官方C＃指南？

它会不会：

• Public Fields
• 私人领域
• 属性
• 构造
• 方法
  ？

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

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

任何提示/建议？

Answer 1

根据StyleCop Rules Documentation，顺序如下。

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

• Constant Fields
• 字段
• 构造
• 终结者（破坏者）
• 代表
• 活动
• 枚举
• 接口（接口实现）
• 属性
• 索引器
• 方法
• 的Structs
• 类

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

• 公共
• 内部
• protected internal
• 保护
• 私有

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

• 静态
• 非静态

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

• 只读
• 非只读

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

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

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

Answer 2

而不是按知名度或项目类型（字段，属性，方法等）进行分组，而不是按功能分组？

Answer 3

这是一个古老但仍然非常相关的问题，所以我要补充一点：当你打开一个以前可能读过或未读过的类文件时，你首先想要的是什么？场？属性？我从经验中意识到，我几乎总是去寻找构造函数，因为最基本的东西是如何构造这个对象。

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

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

有趣的是，这样的重新排序有多大区别。它让我想起曾经如何命令using语句 - 首先使用System命名空间。 Visual Studio＆＃34;组织使用＆＃34;命令使用了这个命令。现在using只是按字母顺序排序，没有给予系统名称空间特殊处理。结果感觉更简单，更清洁。

Answer 4

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

布拉德会说...

  

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

Answer 5

我不知道某种语言或行业标准，但我倾向于将这些内容放在这个顺序中，每个部分都包含在#region中：

使用语句

命名空间

类

私人会员

公共属性

构造

公共方法

私人方法

Answer 6

如前所述，C＃语言中没有任何内容可以决定布局，我个人使用的是区域，我为普通班级做了类似的事情。

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

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

Answer 7

来自StyleCop

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

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

Answer 8

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

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

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

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

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

• 私有
• 内部
• 内部受保护
• 保护
• 公共

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

Answer 9

您可能找到的最接近的是Brad Abrams的“设计指南，托管代码和.NET Framework”（http://blogs.msdn.com/brada/articles/361363.aspx）

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

Answer 10

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

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

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

Answer 11

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

我倾向于将构造者放在下一步。

我的一般评论是你应该坚持每个文件一个类，如果类足够大，以至于属性与方法的组织是一个大问题，这个类有多大，你应该重构它吗？它代表了多重顾虑吗？

Answer 12

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

另外，如果您的课程定义足够长，以使项目的排序更重要，那可能是code smell，表明您的课程过于庞大和复杂，您应该重构。

Answer 13

我保持尽可能简单（至少对我而言）

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

Answer 14

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

Answer 15

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

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

• 常量
• 静态变量
• 字段
• 活动
• 构造（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; }
}