18

在维护了大量散布着#region 的代码（在 C# 和 VB.NET 中）之后，在我看来，这个结构只是程序员的一堆“工作”。将这些乱七八糟的东西放入代码中是可行的，然后它们会使搜索和阅读代码变得非常烦人。

有什么好处？为什么编码人员会费尽心思将其放入他们的代码中。

让我成为一个信徒！

4

17 回答 17

22

已经提出了类似的问题。

但...

我会说不再。它最初的目的是在 .NET 的早期版本中隐藏从 WinForms生成的代码。对于部分课程，这种需求似乎消失了。恕我直言，它现在作为一种组织结构被过度使用，并且没有任何编译器价值。这一切都是为了 IDE。

于 2008-10-03T23:22:41.867 回答
17

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

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

于 2008-10-03T23:19:56.113 回答
14

http://www.rauchy.net/regionerate/ - 自动区域化你的代码；）

我喜欢将大类的部分分组的区域，比如所有属性、所有常量等。我是一个不断折叠代码的人，我当时不需要看到，所以我喜欢区域。

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

于 2008-10-03T23:22:53.457 回答
6

我一直在使用它们。同样，就像其他任何东西一样，它们既可以用于邪恶，也可以用于善良，当然可以成为糟糕设计的标志，但它们可以用来帮助很好地组织代码。

#region Properties

#region Update Section

#region Accessors

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

#Sweep under carpet

正如 Jeff 指出的那样，我觉得它们的奇怪之处在于它们是用于 ui 目的的编译器预处理器命令。我敢肯定 VS 团队可以用另一种方式做同样有用的事情。

于 2008-10-04T01:07:23.387 回答
4

我们的业务对象都有区域——我们喜欢它们。

我们有;

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

根据我们正在处理的业务对象的类型（订阅者等），我们还有一些其他的

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

于 2008-11-17T19:05:13.987 回答
3

我通常不使用代码区域，除非在一种特定情况下 - 依赖属性。尽管在大多数方面使用依赖属性都是一种乐趣，但它们的声明令人眼花缭乱，并且很快就会使您的代码变得混乱。（好像管理 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(
        "ObjectDepthThreshold",
        typeof(int),
        typeof(GotoXControls),
        new FrameworkPropertyMetadata((int)GotoXServiceState.OBJECT_DEPTH_THRESHOLD_DEFAULT,
            FrameworkPropertyMetadataOptions.AffectsRender,
            new PropertyChangedCallback(OnControlValueChanged)
        )
    );

    #endregion

当它倒塌时，你只会看到

public int ObjectDepthThreshold

如果我有多个依赖属性，我喜欢在下一行开始下一个#region。这样一来，您最终将所有这些都分组到您的班级中，并且代码紧凑且可读。

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

于 2012-07-30T21:48:04.073 回答
2

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

几周前，我认为区域很棒，因为它们允许我隐藏我的胖代码，但是在锻炼了我的代码技能之后，我能够让它变得更苗条，现在我适合 7 号班（有人应该做一个测量用于未来的重构！:P)

于 2008-10-03T23:27:46.647 回答
2

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

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

例如，将属性、事件、常量或其他方式分组在一起并没有真正意义，因为如果将事物按功能分组在一起，代码通常更易于维护（例如，使用常量的属性应该接近该常量，而不是靠近其他不相关的属性，只是因为它是属性）。

于 2008-10-04T00:41:13.877 回答
2

有时您的方法必须很长，尤其是在 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

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

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

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

区域仅在用作拐杖或覆盖不良代码时才会出现问题（例如，如果您在同一范围内将区域相互嵌套，这是一个不好的迹象）。

于 2008-11-13T16:16:01.523 回答
2

我经常使用它们而不是注释来对类主体中的功能组进行排序，例如“配置公共接口”、“状态公共接口”、“内部处理”和“内部工作线程管理”。

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

不幸的是，C++ 的区域被破坏了，MS 认为不需要修复它。

于 2008-11-13T16:39:08.840 回答
2

我讨厌过度使用这些。我发现它们有用的唯一想法是隐藏你可能再也不想看到的东西。再说一次，这些东西可能应该在某个图书馆里。

于 2008-11-17T19:14:29.570 回答
1

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

于 2008-10-03T23:34:07.460 回答
1

与任何语言功能一样，区域有可能被误用和滥用，但它们也有其好处。

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

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

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

我在我的代码中使用区域来帮助在我的代码中创建一致的结构，所以我总是一目了然地知道事情在哪里。是的，在重构或添加新功能时（尤其是在由 Visual Studio 自动生成时），这会使事情变得更加困难，但我觉得为了保持一致和结构​​化而付出的代价很小。

于 2008-10-04T01:01:09.967 回答
1

不错的答案，我同意他们的观点，他们说它有时反映了糟糕的编码和设计，但如果您使用 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>

请注意，有一个指向您希望在文档中作为示例公开的方法的源代码示例文件和区域的链接。看这里的结果。该方法需要位于适当的区域，并将自动包含在您的文档中。这就是为什么我还不会扔掉#region。

于 2008-11-13T16:37:35.100 回答
1

我喜欢地区，因为它可以帮助我专注于我正在做的事情。即使该类只有一个方法，我也会使用它们。

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

于 2009-02-23T16:00:53.450 回答
0

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

于 2008-10-03T23:23:19.243 回答
-1

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

于 2009-03-24T09:15:43.073 回答