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

Question

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

它会去:

• 公共领域
• 私人领域
• 属性
• 构造函数
• 方法
  ？

我很好奇是否有关于物品顺序的硬性规定？我到处都是.我想坚持一个特定的标准,所以我可以到处做.

真正的问题是我的更复杂的属性最终看起来很像方法,他们觉得在构造函数之前顶部不合适.

有什么提示/建议吗？

Answer 1

根据StyleCop规则文档,订购如下.

在类,结构或接口中:(SA1201和SA1203)

• 恒定场
• 字段
• 构造函数
• 终结者(Destructors)
• 代表
• 活动
• 枚举
• 接口(接口实现)
• 属性
• 索引
• 方法
• 结构
• 类

在每个组中按访问顺序排列:(SA1202)

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

在每个访问组中,按静态排序,然后是非静态:(SA1204)

• 静态的
• 非静态

在每个静态/非静态字段组中,按readonly排序,然后是非readonly:(SA1214和SA1215)

• 只读
• 非只读

展开的列表是130行,所以我不会在这里展开它.部分展开的方法是:

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

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

Answer 2

而不是通过可见性或项目类型(字段,属性,方法等)进行分组,而不是按功能分组？

Answer 3

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

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

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

有趣的是,这样的重新排序有多大区别.它让我想起了以前如何对using语句进行排序 - 首先使用System命名空间.Visual Studio的"Organize Usings"命令使用了此命令.现在using只是按字母顺序排序,没有对System命名空间给出特殊处理.结果感觉更简单,更清洁.

Answer 4

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

布拉德会说......

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

Answer 5

我不知道语言或行业标准,但我倾向于按照这个顺序排列,每个部分包含在#region中:

使用语句

命名空间

类

私人会员

公共财产

构造函数

公共方法

私人方法

Answer 6

来自 StyleCop

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

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

Answer 7

如前所述,C#语言中没有任何内容可以决定布局,我个人使用的是区域,我为普通课程做了类似的事情.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

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

Answer 8

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

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

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

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

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

• 私人的
• 内部的
• 内部保护
• 受保护
• 民众

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

Answer 9

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

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

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