在类结构方面,是否有一个官方的c#项目顺序指南?
它是这样的:
公共字段 私有字段 属性 构造函数 方法 ?
我很好奇物品的摆放顺序是否有硬性规定?我有点到处都是。我想坚持一个特定的标准,这样我就可以在任何地方使用它。
真正的问题是我的更复杂的属性最终看起来很像方法,它们在构造函数之前的顶部感觉不合适。
任何建议/建议吗?
在类结构方面,是否有一个官方的c#项目顺序指南?
它是这样的:
公共字段 私有字段 属性 构造函数 方法 ?
我很好奇物品的摆放顺序是否有硬性规定?我有点到处都是。我想坚持一个特定的标准,这样我就可以在任何地方使用它。
真正的问题是我的更复杂的属性最终看起来很像方法,它们在构造函数之前的顶部感觉不合适。
任何建议/建议吗?
当前回答
最接近的可能是Brad Abrams的《设计指南、托管代码和。net框架》(http://blogs.msdn.com/brada/articles/361363.aspx)
这里概述了许多标准。我认为相关的章节是2.8。
其他回答
我更喜欢将私有字段与构造函数一起放在顶部,然后将公共接口位放在后面,然后是私有接口位。
此外,如果您的类定义足够长,以至于项的顺序变得很重要,这可能是一种代码气味,表明您的类太庞大和复杂,您应该重构。
我不知道哪种语言或行业标准,但我倾向于按照这样的顺序排列,每个部分都用#区域包装:
使用报表
名称空间
类
私有成员
公共属性
构造函数
公共方法
私有方法
当然,语言中没有任何东西以任何方式强制执行它。我倾向于根据可见性(公共的,然后是受保护的,然后是私有的)对事物进行分组,并使用#regions对相关的事物进行功能分组,而不管它是属性、方法还是其他什么。构造方法(无论是实际的ctor还是静态的工厂函数)通常是在顶部,因为它们是客户需要知道的第一件事。
我所看到的唯一编码指南是将字段放在类定义的顶部。
我倾向于把构造函数放在后面。
我的一般意见是,你应该坚持每个文件一个类,如果类足够大,属性和方法的组织是一个大问题,类有多大,你应该重构它吗?它是否代表多个关注点?
最接近的可能是Brad Abrams的《设计指南、托管代码和。net框架》(http://blogs.msdn.com/brada/articles/361363.aspx)
这里概述了许多标准。我认为相关的章节是2.8。