在类结构方面,是否有一个官方的c#项目顺序指南?
它是这样的:
公共字段 私有字段 属性 构造函数 方法 ?
我很好奇物品的摆放顺序是否有硬性规定?我有点到处都是。我想坚持一个特定的标准,这样我就可以在任何地方使用它。
真正的问题是我的更复杂的属性最终看起来很像方法,它们在构造函数之前的顶部感觉不合适。
任何建议/建议吗?
在类结构方面,是否有一个官方的c#项目顺序指南?
它是这样的:
公共字段 私有字段 属性 构造函数 方法 ?
我很好奇物品的摆放顺序是否有硬性规定?我有点到处都是。我想坚持一个特定的标准,这样我就可以在任何地方使用它。
真正的问题是我的更复杂的属性最终看起来很像方法,它们在构造函数之前的顶部感觉不合适。
任何建议/建议吗?
当前回答
不是按可见性或按项目类型(字段、属性、方法等)分组,而是按功能分组呢?
其他回答
从StyleCop
私有字段,公共字段,构造函数,属性,公共方法,私有方法
由于StyleCop是MS构建过程的一部分,您可以将其视为事实上的标准
我更喜欢将私有字段与构造函数一起放在顶部,然后将公共接口位放在后面,然后是私有接口位。
此外,如果您的类定义足够长,以至于项的顺序变得很重要,这可能是一种代码气味,表明您的类太庞大和复杂,您应该重构。
通常我会遵循下面的模式:
静态成员(通常有其他上下文,必须是线程安全的,等等) 实例成员
每个部分(静态和实例)由以下成员类型组成:
运算符(总是静态的) 字段(在构造函数之前初始化) 构造函数 析构函数(是遵循构造函数的传统) 属性 方法 事件
然后成员按可见性排序(从低到高):
私人 内部 内部保护 受保护的 公共
顺序不是教条:简单的类更容易阅读,然而,更复杂的类需要特定于上下文的分组。
我所看到的唯一编码指南是将字段放在类定义的顶部。
我倾向于把构造函数放在后面。
我的一般意见是,你应该坚持每个文件一个类,如果类足够大,属性和方法的组织是一个大问题,类有多大,你应该重构它吗?它是否代表多个关注点?
我知道这是旧的,但我的命令如下:
公共的,受保护的,私人的,内部的,抽象的
常量 静态变量 字段 事件 构造函数(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; }
}