在类结构方面,是否有一个官方的c#项目顺序指南?
它是这样的:
公共字段 私有字段 属性 构造函数 方法 ?
我很好奇物品的摆放顺序是否有硬性规定?我有点到处都是。我想坚持一个特定的标准,这样我就可以在任何地方使用它。
真正的问题是我的更复杂的属性最终看起来很像方法,它们在构造函数之前的顶部感觉不合适。
任何建议/建议吗?
在类结构方面,是否有一个官方的c#项目顺序指南?
它是这样的:
公共字段 私有字段 属性 构造函数 方法 ?
我很好奇物品的摆放顺序是否有硬性规定?我有点到处都是。我想坚持一个特定的标准,这样我就可以在任何地方使用它。
真正的问题是我的更复杂的属性最终看起来很像方法,它们在构造函数之前的顶部感觉不合适。
任何建议/建议吗?
当前回答
我的偏好是按种类排序,然后减少能见度如下
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
我知道这违反了Style Cop,如果有人能给我一个很好的理由,为什么我应该把一个类型的实现细节放在它的接口之前,我愿意改变。目前,我强烈倾向于把私人成员放在最后。
注意:我不使用公共字段或受保护字段。
其他回答
我不知道哪种语言或行业标准,但我倾向于按照这样的顺序排列,每个部分都用#区域包装:
使用报表
名称空间
类
私有成员
公共属性
构造函数
公共方法
私有方法
我知道这是旧的,但我的命令如下:
公共的,受保护的,私人的,内部的,抽象的
常量 静态变量 字段 事件 构造函数(s) 方法 属性 代表
我还喜欢像这样写出属性(而不是简写方法)
// Some where in the fields section
private int someVariable;
// I also refrain from
// declaring variables outside of the constructor
// and some where in the properties section I do
public int SomeVariable
{
get { return someVariable; }
set { someVariable = value; }
}
我所看到的唯一编码指南是将字段放在类定义的顶部。
我倾向于把构造函数放在后面。
我的一般意见是,你应该坚持每个文件一个类,如果类足够大,属性和方法的组织是一个大问题,类有多大,你应该重构它吗?它是否代表多个关注点?
最接近的可能是Brad Abrams的《设计指南、托管代码和。net框架》(http://blogs.msdn.com/brada/articles/361363.aspx)
这里概述了许多标准。我认为相关的章节是2.8。
不是按可见性或按项目类型(字段、属性、方法等)分组,而是按功能分组呢?