您对使用应用程序语义使用#region 折叠而不是折叠“语法”有何看法。
例如：
#region Application Loop
#region User Management
#region This Kinf of stuffs
而不是
#region Private Routines
#region Public Properties
#region ThisRoutine // (Yes, I've seen this also!)
在这个逻辑中，我开始折叠甚至是常规的身体。我开始喜欢#region 指令（甚至在使用C++ 时使用#pragma region！）。
【问题讨论】：
标签： c# coding-style folding
这表明您在一种类型上做得太多了 - 为什么“应用程序循环”与“用户管理”属于同一类型？如果您发现自己想要这样做，请考虑将功能拆分为不同的类型。
通常我将区域用于接口实现、Equals/GetHashCode 覆盖和运算符 - 但通常仅此而已。
【讨论】：
我更喜欢根据语法将代码分成区域，因为我可以很容易地找到构造函数、被覆盖的方法等等......
【讨论】：
我使用区域来对具有共同/相关目的的方法进行分组。
因此，与其考虑公共、受保护、私有区域，不如考虑“初始化”、“加载和保存”、“事件处理程序”等。
这样做的目的是让折叠类充当功能的摘要或概述，并让您轻松找到您要查找的部分。理想情况下，您通常会选择在整个应用程序的类中使用的几个标准区域“类型”，以便它们都被一致地细分。
【讨论】：
我曾见过开发人员在过去这样做，但最终的结果很少是好的。问题在于期望那些跟随的人会理解分组并正确识别他们添加的正确区域。以我的经验，往往会发生这样的情况，最好的情况是，一个新区域的扩散最终会导致每个功能更改一个，最坏的情况是，新方法在课程结束时被丢弃在任何旧地方或无区域。
我想说的是一个显而易见的方案。最常见的是“私有字段/公共字段/私有属性/私有方法/公共属性/公共方法”方案。 （我个人更喜欢按可见性分组：“公共/内部/私人”，最明显的成员位于顶部，因为这是课程的临时访问者首先会感兴趣的内容，而去哪里仍然非常明显。）
【讨论】：
我唯一一次使用区域是隐藏一堆未实现的接口方法或一堆代码，但我还没有准备好杀死它。
我倾向于认为它是否需要折叠以帮助您跟踪所有文件中的代码过多（或者可能是另一种一般代码异味[或者折叠异味？] ) 如果它不需要折叠，那么折叠唯一能实现的就是让那些不得不去寻找应该展示的代码的人感到沮丧。
我不喜欢对自己隐藏代码。
【讨论】：