类中项目的顺序：字段，属性，构造函数，方法
有没有一个C＃官方指导方针的阶级结构项目的顺序？
它是否去：
- 公共领域
- 私人领域
- 属性
- 构造函数
- 方法
？
我很好奇，如果有一个关于物品顺序的硬性规定？ 我有点太过分了 我想坚持一个特定的标准，所以我可以在任何地方做到这一点。
真正的问题是我的更复杂的属性最终看起来很像方法，他们在构造函数之前的顶部感觉不合适。
任何提示/build议？
根据StyleCop规则文档的顺序如下。
在类，结构或接口内：（SA1201和SA1203）
- 常量字段
- 字段
- 构造函数
- 终结者（破坏者）
- 代表
- 活动
- 枚举
- 接口
- 属性
- 索引
- 方法
- 结构
- 类
在这些组中的每个组中通过访问顺序：（SA1202）
- 上市
- 内部
- 内部保护
- 保护
- 私人的
在每个访问组中，按静态sorting，然后是非静态的：（SA1204）
- 静态的
- 非静态
在每个静态/非静态字段组中，只读（readonly），非只读（SA1214和SA1215）
- 只读
- 非只读
一个展开的列表是130行，所以我不会在这里展开。 展开的方法部分是：
- 公共静态方法
- 公共方法
- 内部静态方法
- 内部方法
- 受保护的内部静态方法
- 保护内部方法
- 受保护的静态方法
- 受保护方法
- 私有静态方法
- 私人方法
该文档指出，如果规定的顺序不合适 – 比方说，正在实现多个接口，并且接口方法和属性应该组合在一起 – 则使用一个部分类将相关的方法和属性组合在一起。
而不是按可视性或项目types（字段，属性，方法等）进行分组，而是按function分组？
我build议使用IDesign或Brad Abram网站上列出的编码标准。 那些是我find的最好的两个。
布拉德会说…
类成员应该按照字母顺序排列，并分成几个部分（字段，构造函数，属性，事件，方法，私有接口实现，嵌套types）
这是一个古老而又非常相关的问题，所以我会补充一点：当你打开一个你可能已经读过的类文件时，你首先要看的是什么？ 场？ 属性？ 我从经验中认识到，几乎总是我去寻找构造函数，因为要理解的最基本的东西是如何构造这个对象。
因此，我已经开始把构造函数放在类文件中，结果在心理上是非常积极的。 把build设者放在一堆其他东西之后的标准build议会让人感到不和谐。
即将到来的C＃6中的主要构造函数提供了一个证据，即构造函数的自然位置在类的最顶端 – 事实上，在开放大括号之前指定了主构造函数。
有趣的是，这样做有多重要。 它让我想起如何using用于命令的语句 – 首先使用System命名空间。 Visual Studio的“组织使用”命令使用了这个顺序。 现在using s只是按字母顺序排列，没有对系统命名空间给予特殊的处理。 结果只是感觉更简单，更清洁。
我不知道一个语言或行业标准，但我倾向于按照这个顺序把每个部分包裹在一个＃地区：
使用语句
命名空间
类
私人会员
公共属性
构造函数
公共方法
私人方法
如前所述，在C＃语言中没有任何规定布局，我个人使用区域，我为一般class级做这样的事情。
public class myClass { #region Private Members #endregion #region Public Properties #endregion #region Constructors #endregion #region Public Methods #endregion }
无论如何，这对我来说是有道理的
从StyleCop
私人领域，公共领域，构造函数，属性，公共方法，私人方法
由于StyleCop是MS构build过程的一部分，因此您可以将其视为事实标准
通常我会尝试遵循下一个模式：
- 静态成员（通常具有其他上下文，必须是线程安全的等）
- 实例成员
每个部分（静态和实例）由以下成员types组成：
- 运营商（总是静态的）
- 字段（在构造函数之前初始化）
- build设者
- 析构函数（ 是遵循构造函数的传统 ）
- 性能
- 方法
- 事件
然后，成员按可见性sorting（从较less到较可见）：
- 私人的
- 内部
- 内部保护
- 保护
- 上市
顺序不是教条：简单的类更容易阅读，但更复杂的类需要上下文特定的分组。
您可能find的最接近的是Brad Abrams的“devise指南，托pipe代码和.NET Framework”（ http://blogs.msdn.com/brada/articles/361363.aspx ）
这里列出了许多标准。 相关部分是2.8我觉得。
我的偏好是按顺序sorting，然后降低能见度，如下所示
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
我知道这违反了风格缔约方会议，如果有人可以给我一个很好的理由，为什么我应该把它的接口之前，我愿意改变一个types的实现细节。 目前，我非常希望把私人成员放在最后。
注意：我不使用公共或受保护的字段。
我所见过的唯一编码指南就是把字段放在类定义的顶部。
我倾向于把构造函数放在下面。
我的一般意见是你应该坚持每个文件一个类，如果这个类足够大以至于属性和方法的组织是一个大问题，那么这个类有多大，你应该重构它吗？ 它代表多重关注？
我更喜欢将私有字段与构造函数一起放在最上面，然后放置公共接口位，然后放置私有接口位。
另外，如果你的类的定义足够长，以便项目的sorting很重要，那么这可能是一个代码异味，说明你的类太笨重和复杂，你应该重构。
语言当然没有任何东西以任何方式执行。 我倾向于通过可见性（公共，然后保护，然后是私人）对事物进行分组，然后使用＃区域在function上对相关事物进行分组，无论它是属性，方法还是其他。 build筑方法（无论是实际的还是静态的工厂function）通常都是正确的，因为它们是客户首先需要知道的。
我尽可能简单（至less对我来说）
枚举
声明
构造函数
覆盖
方法
属性
事件处理程序
订购他们觉得干净的东西，以及维护代码的人。 每个人通常都有一定的个人喜好。
我不认为有必要强制某种特定的风格或订单。
这完全取决于你。 你必须同意一些标准。 即使是坏的标准。 但是最好遵循一个好的标准:)
