在类结构方面,是否有一个官方的c#项目顺序指南?
它是这样的:
公共字段 私有字段 属性 构造函数 方法 ?
我很好奇物品的摆放顺序是否有硬性规定?我有点到处都是。我想坚持一个特定的标准,这样我就可以在任何地方使用它。
真正的问题是我的更复杂的属性最终看起来很像方法,它们在构造函数之前的顶部感觉不合适。
任何建议/建议吗?
在类结构方面,是否有一个官方的c#项目顺序指南?
它是这样的:
公共字段 私有字段 属性 构造函数 方法 ?
我很好奇物品的摆放顺序是否有硬性规定?我有点到处都是。我想坚持一个特定的标准,这样我就可以在任何地方使用它。
真正的问题是我的更复杂的属性最终看起来很像方法,它们在构造函数之前的顶部感觉不合适。
任何建议/建议吗?
当前回答
我不知道哪种语言或行业标准,但我倾向于按照这样的顺序排列,每个部分都用#区域包装:
使用报表
名称空间
类
私有成员
公共属性
构造函数
公共方法
私有方法
其他回答
正如前面提到的,c#语言中没有规定布局的东西,我个人使用区域,我对一个普通类也这样做。
public class myClass
{
#region Private Members
#endregion
#region Public Properties
#endregion
#region Constructors
#endregion
#region Public Methods
#endregion
}
反正对我来说是有道理的
我不知道哪种语言或行业标准,但我倾向于按照这样的顺序排列,每个部分都用#区域包装:
使用报表
名称空间
类
私有成员
公共属性
构造函数
公共方法
私有方法
我尽量让它简单(至少对我来说)
枚举 声明 构造函数 覆盖 方法 属性 事件处理程序
这是一个古老但仍然非常相关的问题,所以我要补充一点:当您打开一个以前可能读过也可能没有读过的类文件时,您首先要查找的是什么?字段?属性呢?我从经验中意识到,我几乎总是去寻找构造函数,因为最基本的事情是理解这个对象是如何构造的。
因此,我开始在类文件中把构造函数放在前面,结果在心理上是非常积极的。将构造函数放在一堆其他东西后面的标准建议让人感觉不协调。
c# 6中即将出现的主构造函数特性提供了证据,证明构造函数的自然位置是在类的顶部——事实上,主构造函数甚至在开大括号之前就被指定了。
有趣的是,这样的重新排序会产生多大的不同。这让我想起了using语句过去是如何排序的——首先是System名称空间。Visual Studio的“Organize Usings”命令使用了这个顺序。现在使用只是按字母顺序排序,没有对系统名称空间进行特殊处理。结果就是感觉更简单、更干净。
最接近的可能是Brad Abrams的《设计指南、托管代码和。net框架》(http://blogs.msdn.com/brada/articles/361363.aspx)
这里概述了许多标准。我认为相关的章节是2.8。