Question

在使用#region（在C＃和VB.NET中）维护大量代码之后，在我看来，这个构造只是程序员的一堆“make work”。将这些东西放入代码中是有效的，然后他们使搜索和阅读代码非常烦人。

有什么好处？编码员为什么要把这个放在他们的代码中呢。

让我成为一个信徒！

Answer 1

已经问过similar question。

但是...

我会说不再。它原本打算在早期版本的.NET中隐藏来自WinForms的生成的代码。对于部分课程，需求似乎消失了。恕我直言，它现在作为一个组织结构被过度使用，并且没有任何编译器价值。这完全适用于IDE。

Answer 2

很多时候，部分和#regions都被用作糟糕设计的拐杖（例如，课程太大或者试图做太多事情）。

迄今为止，我对#regions的最佳使用是在许多不同类中看到的功能分组。例如，具有getter，setter，构造函数和支持字段的值对象。我可能会将这些想法分组到各个地区。然而，关于这是否使代码更清晰或更难阅读，这是一个意见问题。

Answer 3

http://www.rauchy.net/regionerate/ - 自动区分您的代码;）

我喜欢分区大型课程的区域，将所有属性放在一起，所有的常数等等。我是一个经常折叠代码的人，我当时不需要看到所以我喜欢地区为此。

此外，我发现区域在实现接口时非常有用，特别是多个接口。我可以对每个接口方法，属性，事件等进行分组，以便一目了然地查看哪个方法属于哪个接口。

Answer 4

我一直都在使用它们。再一次，就像其他任何东西一样，它们可以用于恶意和善用，并且肯定可以成为糟糕设计的标志，但它们可以用来帮助组织代码。

#region Properties

#region Update Section

#region Accessors

当然你应该避免杰夫的例子

#Sweep under carpet

我发现奇怪的是，正如杰夫指出的那样，它们是用于ui目的的编译器预处理器命令。我确信VS团队可以用另一种方式做一些有用的事情。

Answer 5

我们的Business Objects都有区域 - 我们喜欢它们。

我们有;

业务属性和方法
共享方法
构造
授权
数据访问
活动

我们还有其他几个，具体取决于我们正在处理的业务对象的类型（订阅者等）

对于许多课程而言，区域只是妨碍了 - 但对于我们的标准业务对象，它们为我们节省了大量时间。这些Business Objects是代码生成的，因此它们非常一致。如果不是这样的话，可以到达我想要比杂乱更快的地方，并且一致性使得很容易找到彼此的东西。

Answer 6

我通常不使用代码区域，除了一个特定的情况 - 依赖属性。虽然依赖性属性在大多数方面都很愉快，但它们的声明是一种眼睛，它们很快就会使代码混乱。（好像管理GUI代码还不够挑战......）

我喜欢给区域提供与CLR属性声明相同的名称（在那里复制/粘贴）。通过这种方式，您可以在折叠时看到范围，类型和名称 - 这实际上是您在95％的时间内关注的所有内容。

   #region public int ObjectDepthThreshold

    public int ObjectDepthThreshold
    {
        get { return (int)GetValue(ObjectDepthThresholdProperty); }
        set { SetValue(ObjectDepthThresholdProperty, value); }
    }

    public static readonly DependencyProperty ObjectDepthThresholdProperty = DependencyProperty.Register(
        &quot;ObjectDepthThreshold&quot;,
        typeof(int),
        typeof(GotoXControls),
        new FrameworkPropertyMetadata((int)GotoXServiceState.OBJECT_DEPTH_THRESHOLD_DEFAULT,
            FrameworkPropertyMetadataOptions.AffectsRender,
            new PropertyChangedCallback(OnControlValueChanged)
        )
    );

    #endregion

当它崩溃时你只看到

public int ObjectDepthThreshold

如果我有多个依赖属性，我想在下一行开始下一个#region。这样你最终将所有这些组合在一起，并且代码紧凑且易读。

顺便说一句，如果您只想查看声明，鼠标悬停在它上面。

Answer 7

继续前面提到的Russell Myers所说的话，如果你学会了如何正确地重构你的代码（技能熟练的开发人员必须学习），那么对区域的需求确实不多。

几个星期前，我认为地区很棒，因为他们允许我隐藏我的胖代码，但是在运用我的代码技能后，我能够使它变得更苗条，现在我适合7级（有人应该这样做）这是未来重构的衡量标准！：P）

Answer 8

我发现除了最简单的用法之外，它们都会混淆代码。我们在项目中提倡的唯一用途是IDE使用的（接口实现和设计器代码）。

正确的工具应该用于正确的目的。应编写代码以显示意图和功能，而不是任意分组。将事物组织成访问修饰符分组或其他一些分组似乎是不合逻辑的。我发现代码应该以对特定类有意义的方式组织;毕竟，还有其他工具可以通过访问修饰符查看类成员。对于几乎所有其他区域的使用也是如此;有更好的方法。

例如，将属性，事件，常量或其他组合在一起并不真正有意义，因为如果通过函数将事物组合在一起，代码通常更易于维护（因为，使用常量的属性应该接近于常数，不接近其他不相关的属性，因为它是一个属性）。

Answer 9

有时您的方法需要很长时间，特别是在Web开发方面。在那些情况下（例如当我有一个绑定了大型复杂对象的gridview时），我发现使用区域很有用：

#region Declaring variables for fields and object properties

#region Getting the fields in scope

#region Getting the properties of the object

#region Setting Fields

这些是可以分解的方法的离散部分，但是很难（我必须使用比我喜欢的范围更大的变量或者将大量变量作为'out'传递），它是基本的管道。

在这种情况下，区域是完全可以接受的。在其他人看来，他们是不必要的。

我还将使用区域将方法分组为逻辑组。我为此目的拒绝了部分类，因为在调试时我倾向于打开很多页面，并且对象（或页面或对话框）中的部分类越少，我可以拥有的就越多。我的标签列表（我将其限制为一行，以便我可以看到更多代码）。

当用作拐杖时，区域只是一个问题，或者当它们覆盖不良代码时（例如，如果你在同一范围内将区域嵌套在彼此内部，则这是一个不好的迹象）。

Answer 10

我经常使用它们而不是注释来订购类主体中的功能组，例如“Configuration public interface”，“Status public interface”，“internal processing”和“internal worker thread management”。

使用键盘快捷键“折叠到定义”和“扩展当前块”，我可以轻松导航更大的类。

不幸的是，区域因C ++而中断，而MS认为不需要修复它。

Answer 11

我讨厌过度使用这些。唯一认为我发现它们有用的是隐藏你可能永远不想再看到的东西。然后，那些东西应该在某个地方的图书馆中关闭。

Answer 12

它们可能被过度使用，但我喜欢它们来分离私有方法，公共方法，属性和实例变量。

Answer 13

与任何语言特征一样，地区有可能被滥用和滥用，但它们也有其益处。

它们非常适合创建“折叠”组：

方法，特别是如果你有很多重载方法
接口实施
运算符重载

您还可以使用它来对属性，公共/私有方法，事件，类范围变量等进行分组。

我在代码中使用区域来帮助在代码中创建一致的结构，因此我总是知道事物的位置一目了然。是的，它在重构或添加新函数时会使事情变得更加困难（特别是在Visual Studio自动生成时），但我觉得保持一致和结构化是一个很小的代价。

Answer 14

很好的答案，我同意他们说它有时反映了糟糕的编码和设计，但如果您使用SandCastle创建文档（MSDN样式），＃region实际上是有用的。假设您有一个公共API，并且您想要提供一些使用示例的基类。然后，您将正确记录您的公共方法并添加一个示例区域，您可以在其中复制和粘贴一些代码。问题在于，如果您的基类发生了变化，您最终应该更改示例。更好的解决方案是在您的解决方案中包含一个示例代码项目并将它们组合在一起，因此如果示例代码不是最新的，则每次构建解决方案时都不会编译。那么这与你现在要问自己的地区有什么关系呢。看看这个样本：

/// <example>
    /// The following code sample is an implementation of LoadPublishedVersion() for XmlPageProvider.
    /// <code source="../CodeSamples/EPiServerNET/PageProvider/XmlPageProvider.cs" region="LoadPublishedVersion" lang="cs"/>
    /// </example>

请注意，您希望在文档中作为示例公开方法的源代码示例文件和区域的链接。 See here the result。该方法需要位于适当的区域，并自动包含在您的文档中。这就是为什么我不会扔掉#region的原因。

Answer 15

我热爱地区，因为它有助于我专注于我正在做的事情。即使班级只有一个方法，我也会使用它们。

我使用已经预先填充的区域的代码片段，这样可以减少输入。我觉得这个课程更有条理，并且完成了Code Complete所说的内容，让其他人阅读更好。编译器只是忽略它们，现在它们使代码更具可读性。

Answer 16

真的没有好处。它们是代码味道。使用它们一段时间后，我厌倦了它们。如果您需要按功能分解，请使用分部类。

Answer 17

我的工作日开始于在编辑器中打开文件并单击“全部展开”以隐藏所有区域。之后我就可以开始工作了。

#region指令在.NET中真的有用吗？

17 个答案: