什么是布局一个C#类的最佳方式?

有没有一个标准的方式来布局一个C#文件? 如在字段,然后属性,然后构造函数等?

这是我通常做的,但我想知道是否有一个标准的方式?

  1. 嵌套类或枚举
  2. 字段
  3. 属性
  4. 活动
  5. 构造函数
  6. 公共方法
  7. 私有方法

人们把他们的田地组合在一起,还是把他们的财产? 还是人们不担心订单? Visual Studio似乎很难做到这一点。

编辑 :在这里移动关于ReSharper的其他部分: 使Resharper尊重您的代码顺序的偏好。

我倾向于使用Microsoft StyleCop ,它具有根据规则SA1201设置的顺序:

原因 C#代码文件中的元素与代码中的其他元素相比发生故障。

规则说明当文件中的代码元素不遵循标准sortingscheme时,就会发生违规。

为了符合此规则,文件根目录级别或名称空间内的元素必须按以下顺序排列:

  • 外部别名指令
  • 使用指令
  • 命名空间
  • 代表
  • 枚举
  • 接口
  • 结构

在类,结构或接口中,元素必须按以下顺序排列:

  • 字段
  • 构造函数
  • 终结者(破坏者)
  • 代表
  • 活动
  • 枚举
  • 接口
  • 属性
  • 索引
  • 方法
  • 结构

遵循基于元素types的标准sortingscheme可以提高文件的可读性和可维护性,并鼓励代码重用。

在实现接口时,有时需要将接口的所有成员分组。 如果接口包含不同types的元素,这有时会违反这个规则。 这个问题可以通过使用部分类来解决。

  1. 如果该类不是部分的,则将该部分属性添加到该类中。

  2. 添加具有相同名称的第二个部分类。 可以将它放在原来的类下面的文件中,也可以放在第二个文件中。

  3. 将接口inheritance和接口实现的所有成员移到该类的第二部分。

我认为没有最好的办法。 在布局方面有两件重要的事情需要考虑。 第一个最重要的是一致性。 select一种方法,并确保整个团队同意并应用布局。 其次,如果你的class级变得足够大,你正在寻找那些烦人的属性在哪里(或者必须实现区域以使它们更容易find),那么你的class级可能太大了。 考虑嗅探它,并根据你的味道重构。

要回答整形器问题,请在选项 (在C#节点下)的“ types成员布局”下进行检查。 这并不简单,但可以更改布局顺序。

我不相信地区一定是坏代码的标志。 但是要确定你将不得不查看你的。 正如我在这里所说的这是我如何区分我的代码。

枚举
声明
构造函数
方法
事件处理程序
属性

但主要的是保持一致和有目的的。

我倾向于聚集私人数据,并倾向于聚集function组中的相关方法/属性。

public class Whatever { // private data here int _someVal = kSomeConstant; // constructor(s) public Whatever() { } #region FabulousTrick // sometimes regionize it // fabulous trick code private int SupportMethodOne() { } private double SupportMethodTwo() { } public void PerformFabulousTrick(Dog spot) { int herrings = SupportMethodOne(); double pieces = SupportMethodTwo(); // etc } #endregion FabulousTrick // etc } 

您可以尝试使用Regionerate来帮助解决这个问题。 我真的很喜欢,这是一个斯科特Hanselmanselect。

如上所述,我不认为有这样一个最好的方法。 但有些组织可以帮助你的程序员。

在一个长期的项目中,你花费多less时间上下一个或多个源文件,试图find你的一个函数。

所以我以这种方式利用了#region很多 –

  1. region事件 :这个类使用的所有事件引用(至less在这个特定的部分类中)。

  2. 区域控件 :与表单上的控件直接交互的所有function。

  3. 地区MDI :设置mdi

    那么会有一些与function而不是界面有关的,

  4. 区域正则expression式search

当我走的时候,我总是这样做,但是使用了我一直使用的模式。 我必须说,一些程序员拿起我的作品告诉我很容易跟随,而其他的则是杂乱无章的。

一半的时间和另一半的时间,另一半的时间,你可以让一半的人讨好。 我想温斯顿·克里奇尔说过。

无论什么让你更有成效。 有些像属性访问器旁边的私有字段,有些像构造函数上面的字段一样。 可以帮助的最大的事情是将“像”这样的元素分组。 我个人喜欢把私人方法,私人财产等

不pipe你觉得什么让你更有成效,并帮助你保持你的代码,你可以再试一些东西。

各自为政,但我倾向于遵循MSDN帮助所遵循的顺序。

我也不喜欢嵌套类或枚举,而是为它们创build单独的文件,这也使得编写unit testing更容易(因为在需要添加/修复/重构testing时很容易find相关的testing文件)。

恕我直言,顺序并不重要,因为VS使得查找所有成员非常容易(特别是如果你按照一个类/接口/枚举每个文件的方法),如果你想build立文档,Sandcastle会将它们分组,更关心给他们有意义的名字。

除了在类文件中保持一组一致的区域之外,我还按字母顺序保留区域的所有组件。 在阅读代码时,我倾向于拥有一些“可视化内存”,这让我疯狂得不得不使用导航下拉菜单来查找文件中的代码,因为它到处都是。

我使用以下布局:

事件全局variables/类全域私有/内部属性方法公共/保护属性方法嵌套类(尽pipe我尽量避免这些)

我也坚信每个文件有一个代码“事物”(类,接口或枚举),文件名与“事物”名称相同。 是的,它使一个更大的项目,但它使得find事情变得非常容易。