语义 #region 用法
您对使用应用程序语义使用 #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！）。
What's your opinion about using #region folding using application semantic, instead of folding for "syntax".
For example:
#region Application Loop
#region User Management
#region This Kinf of stuffs
instead of
#region Private Routines
#region Public Properties
#region ThisRoutine // (Yes, I've seen this also!)
In this logic, I'm starting fold even routine bodies. I'm starting to love #region directive (even using #pragma region when using C++!).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我过去见过这样做的开发人员，但最终结果很少是好的。问题在于期望那些遵循的人能够理解分组并正确识别其添加的正确区域。根据我的经验，最容易发生的情况是，在最好的情况下，最终会出现新区域的激增，每个功能变化都会有一个新区域，而在最坏的情况下，新方法会在任何旧地方被废弃，或者在课程结束时没有区域。
我想说采用一个显而易见的方案。最常见的是“私有字段/公共字段/私有属性/私有方法/公共属性/公共方法”方案。 （我个人更喜欢按可见性进行分组：“公共/内部/私人”，更可见的成员位于顶部，因为这是班级的临时访问者首先感兴趣的内容，而且内容的去向仍然非常明显。）
I've seen developers who do this in the past and the end result is rarely good. The problem is with the expectation that those who follow will understand the groupings and correctly identify the correct region for their additions. In my experience what tends to happen is that, at best, one ends up with a proliferation of new regions, one per each functional change and, at worst, new methods junked in any old place or regionless at the end of the class.
I'd say go with a scheme that is obvious. The most common is the 'Private Fields/ Public Fields / Private Properties / Private Methods / Public Properties / Public Methods' scheme. (Personally I favour grouping by visibility: 'Public / Internal / Private' with the more visible members at the top as that is what a casual visitor to a class is going to be interested in first and what goes where is still blindingly obvious.)
这表明您在一种类型中做了太多事情 - 为什么“应用程序循环”与“用户管理”属于同一类型？如果您发现自己想要这样做，请考虑将功能分为不同的类型。
通常，我使用区域来实现接口、Equals/GetHashCode 覆盖和运算符 - 但这通常就是全部。
That would suggest you're doing too much in one type - why would an "application loop" be in the same type as "user management"? If you find yourself wanting to do this, consider splitting the functionality into different types.
Typically I use regions for interface implementations, Equals/GetHashCode overrides, and operators - but that's usually all.
我唯一一次使用区域是隐藏一些东西，比如一堆未实现的接口方法或一堆用于砍伐的代码，但我还没有准备好杀死它。
我倾向于认为，如果它需要折叠来帮助您跟踪所有内容，则文件中的代码太多（或者可能是另一个通用代码气味[或者是折叠气味？]）并且如果它不需要折叠，折叠所能实现的唯一效果是让那些必须去寻找应该显示的代码的人感到沮丧。
我不喜欢对自己隐藏代码。
The only time I use a region is to hide something like a bunch of non-implemented interface methods or a bunch of code which is for the chop but I'm not quite ready to kill it.
I tend to think if it needs folding to help you keep track of it all there is too much code in the file (or maybe another general code smell [or is the folding the smell?]) and if it doesn't need folding the only thing folding will achieve is frustrating people who have to go looking for code which should be on display.
I'm not a fan of hiding code from myself.
我更喜欢根据语法将代码划分为多个区域，因为我可以轻松找到构造函数、重写的方法等等......
I prefer dividing my code into regions based on syntax, because I can easily find the constructor, overridden methods and so on...
我使用区域对具有共同/相关目的的方法进行分组。
因此，不要考虑公共、受保护、私有区域，而是考虑“初始化”、“加载和保存”、“事件处理程序”等。
这样做的目的是让折叠类充当功能的摘要或概述，并让您轻松找到所需的零件。理想情况下，您通常会选择在应用程序的类中使用的一些标准区域“类型”，以便它们都能一致地细分。
I use regions to group methods with a common/related purpose.
So, rather than public, protected, private regions, think of "Initialisation", "Load and save", "Event handlers", etc.
The purpose of this is for the folded class to act as a summary or overview of the functionality, and make it easy to find the parts you are looking for. Ideally, you will generally settle on a few standard region "types" that you use throughout your application's classes so that they are all consistently subdivided.