是否有标准的 C# 文件布局方式？比如字段，然后是属性，然后是构造函数等等？
这是我通常做的，但我想知道是否有标准方法？
人们是将他们的领域组合在一起，还是将它们与属性放在一起？还是人们不担心订单？ Visual Studio 似乎很难做到。
编辑：将有关 ReSharper 的其他部分移至此处：Make Resharper respect your preference for code order.
【问题讨论】：
标签： c# coding-style
我倾向于使用Microsoft StyleCop，它根据规则SA1201有一个固定的顺序：
原因 C# 代码中的一个元素 文件出现故障 代码中的其他元素。
规则说明 违反此 规则发生时代码元素 文件内不遵循标准 订购方案。
为遵守此规则，元素位于 文件根级别或在 命名空间必须位于 以下顺序：
- 外部别名指令
- 使用指令
- 命名空间
- 代表
- 枚举
- 接口
- 结构
- 类
在类、结构或接口中， 元素必须位于 以下顺序：
- 字段
- 构造函数
- 终结器（析构函数）
- 代表
- 活动
- 枚举
- 接口
- 属性
- 索引器
- 方法
- 结构
- 类
遵守标准排序 基于元素类型的方案可以 增加可读性和 文件的可维护性和 鼓励代码重用。
当实现一个接口时，它是 有时希望将所有人分组 旁边的接口成员之一 其他。这有时需要 违反此规则，如果接口 包含不同类型的元素。 这个问题可以通过 使用部分类。
将部分属性添加到类中，如果该类尚未 部分。
添加第二个同名的分部类。可以放置 这在同一个文件中，就在下面 原班，或在一秒钟内 文件。
移动接口继承和接口的所有成员 实施到第二部分 班级。
【讨论】：
我认为没有最好的方法。在布局方面有两件重要的事情需要考虑。首先最重要的是一致性。选择一种方法并确保整个团队都同意并应用布局。其次，如果您的班级变得足够大，以至于您正在搜索那些讨厌的属性所在的位置（或者必须实现区域以使其更容易找到），那么您的班级可能太大了。考虑嗅探它，并根据你的气味进行重构。
要回答 reshaper 问题，请检查 Options 中的 Type Members Layout（在 C# 节点下）。不简单，但是可以改变布局顺序。
【讨论】：
我不认为区域一定是错误代码的标志。但要确定你将不得不审查你所拥有的。正如我所说的here，这就是我对代码进行区域化的方式。
枚举
声明
构造函数
方法
事件处理程序
属性
但最重要的是保持它的一致性和目的性。
【讨论】：
我倾向于将私有数据聚集在一起，并倾向于将相关的方法/属性聚集在功能组中。
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 来帮助解决这个问题。我真的很喜欢它，它是 Scott Hanselman 的选择。
【讨论】：
如前所述，我认为没有最好的方法。但是某些组织确实可以帮助您成为程序员。
在一个漫长的项目中，您多久会花时间在一个或多个源文件中查找您的功能之一。
所以我以这种方式大量使用#region -
区域事件：该类使用的所有事件引用（至少在这个特定的部分类中）。
区域控件：直接与表单上的控件交互的所有函数。
region MDI : 设置mdi
然后会有一些与功能而不是界面有关，
区域正则表达式搜索
我会边走边编，但使用我一直使用的相同模式。我必须说，一些接手我的工作的程序员告诉我，它很容易理解，而另一些人则说它很混乱。
你可以在一半的时间取悦一半的人，在四分之一的时间里取悦另一半的人，在另一半的时间里混淆包括你自己在内的所有人。我认为 Winston Chrchil 是这么说的。
【讨论】：
让你更有效率的东西。有些喜欢属性访问器旁边的私有字段，有些喜欢构造函数上方的字段。最大的帮助是对“喜欢”元素进行分组。我个人喜欢将私有方法、私有属性等组合在一起。
反复尝试一些事情，无论您觉得什么都能提高工作效率并帮助您维护代码。
【讨论】：
每个都有自己的，但我倾向于遵循 MSDN 帮助遵循的相同顺序。
我也不喜欢嵌套类或枚举，而是为它们创建单独的文件，这也使编写单元测试更容易（因为当您需要添加/修复/重构测试时，很容易找到关联的测试文件)。
恕我直言，顺序并不那么重要，因为 VS 可以很容易地找到所有成员（特别是如果您遵循每个文件一个类/接口/枚举的方法），如果您想构建文档，Sandcastle 会将它们分组，所以我会更关心给他们起有意义的名字。
【讨论】：
除了在类文件中保持一组一致的区域之外，我还按字母顺序保持区域的所有组件。在阅读代码时，我往往有一点“视觉记忆”，这让我不得不使用导航下拉菜单在文件中查找代码，因为它到处都是。
【讨论】：
我使用以下布局：
事件 全局/类范围的字段 私人/内部 特性 方法 公共/受保护 特性 方法 嵌套类（尽管我尽量避免这些）
我也坚信每个文件有 1 个代码“事物”（类、接口或枚举），文件名与“事物”名称相同。是的，它是一个更大的项目，但它使查找东西变得非常容易。
【讨论】：