Question

我最近继承了一些C＃代码，其中文件中的几乎每个项目都包含在一个单独的#region / #endregion块中 - 每个类，每个函数，每个属性，每个枚举，但不包括字段。这些中的每一个又被包裹在“分组”#region中（例如“属性”，“构造函数”，“方法”等）。单个函数有多个重载具有不同的参数列表，但它们每个都包含在具有相同名称的单个区域中，而不是包含所有三个重载的单个区域。编写此代码的人不再与公司合作，并且从源代码控制的历史记录中可以看出，这些代码存在于初始提交中，并且随着新属性和方法的添加，该实践将继续贯穿代码的后续版本。

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

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

编辑：我选择了Jonathan的答案，因为它为人们选择这样做提供了新的理由。感谢您的讨论！

Answer 1

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

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

话虽如此 - 区域是一个功能，并且它是非常个人的偏好是否以及使用它们多少，因为它们对编译的代码没有影响。

Answer 2

好原因？可能不是。

更像是过度热心的评论，或者可能是一个可以做到这一点的工具。

我的地区通常包括：

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

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

Answer 3

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

Answer 4

我会说这是过度热心，没有考虑到地区的概念。

Answer 5

当谈到非自动实现的属性时，它可以使代码更容易导航。例如，下面的许多代码（在区域内）只是赘肉 - 它总是看起来一样（因为属性实际上不应该有副作用）。单行说“Property - Name”可以更好地导航。

#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

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

最后它是一个编码标准和宗教。如果您不喜欢它，请不要将其用于您的个人项目。如果您因标准要求使用它，请使用它。

Answer 6

这是过度的区域化。没有充分的理由用一个区域声明来包装每个函数，每个枚举。

我会考虑这种不好的做法，并将区域代码的概念推得太远。

通常，我会做以下区域：

   1. Constructors 
   2. Public Methods
   3. Private Methods

等

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

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

6 个答案: