在类结构方面,是否有一个官方的c#项目顺序指南?

它是这样的:

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

我很好奇物品的摆放顺序是否有硬性规定?我有点到处都是。我想坚持一个特定的标准,这样我就可以在任何地方使用它。

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

任何建议/建议吗?


当前回答

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

使用报表

名称空间

私有成员

公共属性

构造函数

公共方法

私有方法

其他回答

这是一个古老但仍然非常相关的问题,所以我要补充一点:当您打开一个以前可能读过也可能没有读过的类文件时,您首先要查找的是什么?字段?属性呢?我从经验中意识到,我几乎总是去寻找构造函数,因为最基本的事情是理解这个对象是如何构造的。

因此,我开始在类文件中把构造函数放在前面,结果在心理上是非常积极的。将构造函数放在一堆其他东西后面的标准建议让人感觉不协调。

c# 6中即将出现的主构造函数特性提供了证据,证明构造函数的自然位置是在类的顶部——事实上,主构造函数甚至在开大括号之前就被指定了。

有趣的是,这样的重新排序会产生多大的不同。这让我想起了using语句过去是如何排序的——首先是System名称空间。Visual Studio的“Organize Usings”命令使用了这个顺序。现在使用只是按字母顺序排序,没有对系统名称空间进行特殊处理。结果就是感觉更简单、更干净。

最接近的可能是Brad Abrams的《设计指南、托管代码和。net框架》(http://blogs.msdn.com/brada/articles/361363.aspx)

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

从StyleCop

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

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

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

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

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

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

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

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

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

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

我倾向于把构造函数放在后面。

我的一般意见是,你应该坚持每个文件一个类,如果类足够大,属性和方法的组织是一个大问题,类有多大,你应该重构它吗?它是否代表多个关注点?