是否有充分的理由将单个属性包装在 c# 中的#region 中？答案

【问题标题】：Are there good reasons to wrap a single property in a #region in c#?是否有充分的理由将单个属性包装在 c# 中的#region 中？
【发布时间】：2011-08-18 16:03:28
【问题描述】：

我最近继承了一些 C# 代码，其中文件中的几乎每个项目都包装在单独的 #region/#endregion 块中——每个类、每个函数、每个属性、每个枚举，但不是字段。这些中的每一个都依次包装在“分组”#region（例如“Properties”、“Constructor”、“Methods”等）中。具有不同参数列表的单个函数有多个重载，但它们每个都包装在具有相同名称的单独区域中，而不是所有三个重载的单个区域。编写此代码的人已不在公司，从源代码控制的历史来看，这些似乎存在于最初的提交中，并且随着新属性和方法的添加，该实践通过代码的后续版本继续进行。

知道为什么会这样做吗？一些想法：

一个过分热心的 VS 功能（或代码清理工具）自动插入了 #region/#endregion 块，而作者并没有删除它们。
有一个 IDE 可以折叠区域而不是函数，因此这是实现语法折叠所必需的。
这是一种在实现代码之前将其结构存根的方法。

编辑：我选择了乔纳森的回答，因为它为人们可能选择这样做提供了一个新的理由。感谢讨论！

【问题讨论】：

Overzealous 我在工作的地方也有类似的问题，不是很糟糕，但仍然非常烦人 - 所以我刚刚关闭了该功能：取消勾选选项 -> 文本编辑器-> C# -> 高级 -> 打开文件时进入大纲模式

标签： c# coding-style

【解决方案1】：

这似乎是开发人员不了解如何有效使用 IDE（即：方法的代码折叠、使用编辑器中的导航功能等）的结果。我个人会删除大部分（全部？）这些区域，因为它们实际上在很多方面对你不利。

在区域包装东西确实有它的位置，但我认为它实际上通常会适得其反。它隐藏了代码——我经常发现让开发人员更容易留下不适当的代码，错过良好的重构机会，允许复杂的方法（应该被拆分）随着时间的推移而蔓延，并且让类型聚集在一起太大。

话虽如此 - 区域是一项功能，是否使用以及使用多少取决于个人喜好，因为它们对编译后的代码没有影响。

【讨论】：

区域肯定会妨碍您，而且我已经看到太多次您按 CTRL-F 进行某些操作，但由于区域已折叠而找不到它。但它们确实使代码在一开始就看起来“有条理”。
@Jack：没错，说到点子上了。好的编码约定标准做同样的事情。（顺便说一句，这就是我的公司对开发人员强制执行 StyleCop 规则的原因 - 工具已经到位以强制保持一致性。）
或者甚至更好的方法，它是如此之大，以至于有人在区域中隐藏了它的一部分，而不是将函数分开
@Jack CTRL-F 仍会在折叠区域中找到某些内容。我同意你所在地区的组织，但不同意这种说法。

【解决方案2】：

当涉及到非自动实现的属性时，它可以使代码更易于导航。例如，许多以下代码（在区域内）只是多余的绒毛——看起来总是一样的（因为属性真的不应该有副作用）。单行显示“属性 - 名称”更便于导航。

#region Property - Name
private string _name;
/// <summary>
/// Gets or sets the name of the customer.
/// </summary>
/// <remarks>
/// This should always be the full name of the customer in the format {First Name} {Last Name}.
/// </remarks>
/// <example>
/// customer.Name = "Joe Bloggs";
/// </example>
/// <seealso cref="Customer"/>
/// <value>
/// The name of the customer.
/// </value>
public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}
#endregion

但是，就“成员类型”（方法、属性、构造函数、字段）而言，我觉得它使代码更难导航；但是其他人认为它更容易。

归根结底，它是一种编码标准和宗教信仰。如果您不喜欢它，请不要将其用于您的个人项目。如果您因标准而需要使用它，请使用它。

【讨论】：

【解决方案3】：

好的理由？可能不是。

更像是过分热心的评论，或者可能是这样做的工具。

我的地区通常包括：

#region - Public Methods
#region - Private Methods
#region - Protected Methods
#region - Data Members
#region - Properties

也许他们正在使用“自动生成的帮助”类型的文档来寻找区域而不是 cmets 来构建“帮助文档”？

【讨论】：

如果方法的访问修饰符改变会发生什么？是否依赖开发人员将其剪切粘贴到正确的区域，或者您是否有工具可以自动执行此操作？无论哪种方式，这似乎都是不必要的工作创建，并且会为您的版本控制差异增加噪音，从而更难理解任何提交中更改了哪些代码。

【解决方案4】：

对我来说听起来像是一个可怕的用法。我唯一的想法是有人认为这是记录代码的好方法。我希望消除这种对区域的过度利用。

【讨论】：

【解决方案5】：

我会说这过于热心并且没有考虑到区域的概念。

【讨论】：

不应该像函数在自己的类中结束吗？
抱歉术语使用松散

【解决方案6】：

这是过度区域化。没有充分的理由用区域语句包装每个函数、每个枚举。

我会认为这是一种不好的做法，并且将区域代码的概念走得太远了。

通常，我会做以下地区：

   1. Constructors 
   2. Public Methods
   3. Private Methods

等等

某种逻辑分组。您描述的区域划分似乎不合逻辑。

【讨论】：