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


Order of items in classes: Fields, Properties, Constructors, Methods

是否有关于分类结构的项目顺序的官方C指南？

它去了吗？

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

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

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

有什么建议吗？

相关讨论

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

在类、结构或接口中：(SA1201和SA1203)

  • 恒定场
  • 领域
  • 构造函数
  • 终结器(析构函数)
  • 代表们
  • 事件
  • 枚举类型
  • 接口(接口实现)
  • 性质
  • 索引器
  • 方法
  • 结构体
  • 班

在这些组中，按访问顺序排列：(SA1202)

  • 公众的
  • 内部的
  • 内部受保护
  • 受保护的
  • 私有的

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

  • 静止的
  • 非静态的

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

  • 只读
  • 非只读

展开的列表有130行长，所以我不会展开它。展开的方法是：

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

文档注意到，如果指定的顺序不合适(例如，正在实现多个接口，并且接口方法和属性应分组在一起)，那么使用分部类将相关的方法和属性分组在一起。

相关讨论

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

相关讨论

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

因此，我开始将构造函数放在类文件中的第一位，结果在心理上非常积极。把构造器放在其他事情之后的标准建议感觉不协调。

C 6中即将出现的主要构造函数特性提供了一个证据，证明构造函数的自然位置在类的最顶端——事实上，甚至在左大括号之前就已经指定了主要构造函数。

有趣的是，像这样重新排序有多大的区别。它提醒了我以前如何对using语句进行排序——首先使用系统名称空间。Visual Studio的"Organize using"命令使用了此顺序。现在，usings只是按字母顺序排列，没有对系统名称空间进行特殊处理。结果只是感觉简单和干净。

相关讨论

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

布拉德会说…

Classes member should be alphabetized, and grouped into sections (Fields, Constructors, Properties, Events, Methods, Private interface implementations, Nested types)

相关讨论

我不知道语言或行业标准，但我倾向于按此顺序排列，每个部分都包装在一个区域中：

使用语句

命名空间

等级

私人成员

公共财产

构造函数

公共方法

私有方法

相关讨论

如前所述，在C语言中没有规定布局的内容，我个人使用区域，我为一个普通类做类似的事情。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

不管怎样，这对我来说是有意义的

相关讨论

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

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

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

  • 运算符(始终是静态的)
  • 字段(在构造函数之前初始化)
  • 构造函数
  • 析构函数(是遵循构造函数的传统)
  • 性质
  • 方法
  • 事件

然后按可见性(从低到高)对成员排序：

  • 私有的
  • 内部的
  • 内部保护
  • 受保护的
  • 公众的

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

来自StyleCop

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

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

相关讨论

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
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

我知道这违反了样式cop，如果有人能给我一个很好的理由，为什么我应该将类型的实现细节放在我愿意更改的接口之前。目前，我更倾向于把私人会员排在最后。

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

相关讨论

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

这里概述了许多标准。我想相关章节是2.8节。

我尽量保持简单(至少对我来说)

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

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

另外，如果类定义足够长，以至于项目的排序非常重要，那么这可能是一种代码味道，表明您的类太庞大和复杂，您应该重构。

我看到的唯一的编码指导原则就是将字段放在类定义的顶部。

我倾向于把建设者放在后面。

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

相关讨论

我知道这是旧的，但我的顺序如下：

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

  • 常量
  • 静态变量
  • 领域
  • 事件
  • 构造函数(s)
  • 方法
  • 性质
  • 代表们

我还喜欢写出这样的属性(而不是速记方法)

1
2
3
4
5
6
7
8
9
10
11
12
// 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; }
}

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

相关讨论