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

此外，如果您的类定义足够长，以至于项的顺序变得很重要，这可能是一种代码气味，表明您的类太庞大和复杂，您应该重构。

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

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

常数字段 字段 构造函数 终结器(析构函数) 代表 事件 枚举 接口(接口实现) 属性 索引器 方法 结构体 类

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

公共 内部 保护内部 受保护的 私人

在每个访问组中，依次按静态、非静态排序:(SA1204)

静态 非静态

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

只读的 non-readonly

展开的列表有130行长，所以这里就不展开了。展开的方法部分为:

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

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

正如前面提到的，c#语言中没有规定布局的东西，我个人使用区域，我对一个普通类也这样做。

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

反正对我来说是有道理的

我不知道哪种语言或行业标准，但我倾向于按照这样的顺序排列，每个部分都用#区域包装:

使用报表

名称空间

类

私有成员

公共属性

构造函数

公共方法

私有方法

通常我会遵循下面的模式:

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

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

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

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

私人 内部 内部保护 受保护的 公共

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

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